LTRU

• Charter

My notes

• Very political, just like timezones -- registry maintainers have to evaluate legitimacy of claim. Is it legitimate to register Cornish? Welsh? What if somebody wants to register North Welsh separate from mainstream Welsh? What if the Welsh parliament things that the splinter Welsh language is bogus? Klingon? Thus:

Maintenance of the registry requires that as codes are assigned or
   withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language
   Subtag Reviewer MUST evaluate each change, determine whether it
   conflicts with existing registry entries, and submit the information
   to IANA for inclusion in the registry.

• as with most IANA things, just a registry, not a service

OSCon gossip

• The Hula guy came off as a jerk -- very odd reasons for supporting CalDAV, dismissive of peoples' interest in why Hula had been open sourced, ignorant of other calendar applications and what interoperability is and why users care.
• Lots of interest in interoperability with Outlook, Exchange, and OSAF stuff

Server status

Server hiring

• Server job:
  • We've only gotten 2 resumes. What's up with that?
  • Bobby Rullo will be in tomorrow -- BCM will follow up to make sure the interview schedule is set
  • 10:00 am the interviewers will get together to discuss what the job is (make sure we're interviewing for the same thing)
• Designer job: Nothing happened while I was gone.
  • BCM will screen designers
• Program manager? Still need to discuss this at a high level as well as see what our candidates have for strengths in this area

Status

• Cosmo:
  • supporting GET and PUT together with iCalendar parsing
  • Jackrabbit new version has ETags and PROPPATCH so we'll need to update to that

• Discussion of timezone services
  • What if the timezone information were hosted on CalDAV servers and CalDAV clients downloaded from there? The problem BCM pointed out with that is that CalDAV clients will actually visit several CalDAV servers -- what if those several servers are out of date with respect to each other? Must the client keep several TZ databases, one from each CalDAV server? I think this means that it's best to have a central service. [ Should tell Cyrus]
  • The way we'd build a TZ service (BCM and me) would be to host a WebDAV collection hosting VTIMEZONE components. The client would PROPFIND the collection to see if any of the ETags had changed and then would GET any changed VTIMEZONE components. We'd also add a live collection property similar to an ETag to indicate whether anything in the collection had changed at all.

• Plans for interop Sept 13-15
  • Cosmo will have Get and PUT testable by then and a few other things, but not REPORTs.
  • BCM will follow up on what interoperability testing will mean (what requests the Mozilla and ISAMET clients will try to do first) to see if this should influence the sequencing of implementation of CalDAV features in Cosmo.

• Major goals for Scooby
  • Be Chandler-like
  • Get something working soon, even if small
  • Use the Web in the best way
• Balance among these!?!

Scooby Next Steps

• Matt will post his research and recommendations on AJAX libraries to the Wiki
  • Leading candidate: Prototype -- even though it's not really idiomatic JavaScript
  • We're leaning strongly towards using a library so that other people are responsible for supporting multiple browsers, fixing bugs, and handling new browser versions

• Outlining views and pages

• Matt's next task is to start stripping the custom stuff out of the mockup (thx to Brendan) and replace it with library calls -- this also means giving the mockup a real backend -- but the backend won't be Cosmo yet because Cosmo's not ready yet

• Matt will then build a JSP to put together the page...

• BCM is keen on using CalDAV as the interface between the WebUI^? and the Cosmo backend wherever possible. We realize that this isn't how other people (Hula, RPI) are doing it -- they are doing non-standard "protocols" over POST the way most AJAX apps do.
• BCM mentioned iCal4J -- iCalendar parsing library