[Cosmo-dev] Cosmo and Scooby URLs

[Brian Moseley]

On 6/19/06, Ted Leung <twl at osafoundation.org> wrote:
>
> On Jun 16, 2006, at 2:40 PM, Brian Moseley wrote:
> >
> > that sounds rather like an argument for using microsoft
> > technologies :)
>
> I thought that you were the one arguing for web services
> integration.  As far as I know, there are no standardized API's for
> webservices.    It's hard to see wanting interop with the large web
> services as equivalent to rewriting Cosmo in C#.

that's not what i meant :) i was having fun with john's suggestion
about business reasons being given more consideration than technical
reasons when making technical decisions.

> I used the term blogpostware refers to calatom's origins on a blog
> post or presentation to a small group of people, not its
> usefulness.   I have no doubt that if calatom is useful that people
> will adopt it and tools will get built.   But  of the two, GData has
> much more visibility than calatom.   GData also has the advantage of
> not being restricted to calendar data only.    All I am really saying
> is that we have to choose the order in which we implement this stuff,
> and that if I were implementing this support (which I am not), I
> would do GData support first, and then calatom.

calatom isn't restricted to calendar data either. "calatom" is really
a misnomer. the actual idea is to use atom syndication and atom
publishing to implement crud operations on server data.

notice the "collection introspection document" referenced at
<http://robubu.com/?p=6>. this is pretty similar to what bobby
proposed earlier in the thread (altho the service and workspace
elements might more properly be part of a "home directory collection
introspection document"). as the author of the post mentions, the
properties defined by caldav could be communicated here as well,
including the acceptable calendar resource types and formats,
language, description, timezone, etc.

it's a pretty interesting proposal, and while it relegates issues like
advanced querying and access control to "ongoing research" status,
it's a great start.

in any event, i'm okay with doing gdata first. it's a good way to
learn more about using atom for full crud. but i really want to push
on atom publishing's collection introspection documents. i really
think this is the right way for us to go wrt to GET against
collections.