[Cosmo-dev] Cosmo URL Scheme

[Brian Moseley]

On 9/29/06, Jared Rhine <jared at wordzoo.com> wrote:

> Yes, I'm for having this conversation now, though it's too big to sort out
> all the issues and have a lock by 0.5.0.  It's important to the hosted
> service to have stable URLs for at least sections of the Cosmo services, so
> I've a sticky-note tracking that item: "stable URLs".  I suggest changing a
> couple of things for 0.5.0 that seem to have easy consensus, then making
> some more changes over the 0.6.0 cycle if additional things get sorted out.

i think the final url specification should fall out of the final 1.0
ui design. the ui parts of the app are the ones that are in the must
flux. the protocol url space is much simpler.

> It's probably better to leave it in place for 0.5.0, because it's easy to
> miss a couple spots and have bugs.  And since we're not branching 0.5 yet,
> any experiments should be kept out of trunk it seems until after the branch
> or consensus on changes.

agree. in fact i don't see any pressing need to change anything for .5.

> > /pim - the cosmo PIM ui
>
> Yes.

disagree. nowhere in chandler do we call anything "pim", and i think
we should stick as close to a common vocabulary with chandler as
possible. chandler does have things like calendar view and list view
(or is that table view?) and dashboard. these terms should be
reflected in our urlspace - /calendar, /list, /dashboard.

> > /admin - purely server admin related stuff (add/remove users, server
> > status, future hosted service related features)
>
> That's probably not a bad idea.  I generally wind up wanting to add admin
> tree to web sites at least as they mature and putting in a directory will
> make it easier to manage authentication. +1.  Should probably be fleshed out
> before concluding it's big enough to be appropriate.

this fully depends on how the admin functionality gets integrated into
the overall ui design. there are places in the ui where being an admin
gives you extended functionality - repository browsing for example,
where admins can see everybody's home collections (and eventually even
those that have otherwise fully restrictive acls). the only true
admin-only functionality right now is user mgmt and someday there will
be server-wide configuration). those may or may not merit their own
urlspaces.

we have a very flexible security configuration scheme, so while its
true that /admin/* is easy to protect, so would be /users and /user/*.

> > /help (or /info?) - all help/information related pages (currently in
> > help.jsp and about.jsp, but potentially more if help system is expanded)
>
> /doc?  I like /help better than /info.

i like /help best. i think it's what users would expect.

> > /account (or something different?) - user account related stuff: login,
> > home directory browsing,
>
> I like having an /account, but not sure home directory browsing belongs
> there.  I was thinking more like /pim, as the pim eventually grows to
> encompass document management, etc.

again, depends on how the overall ui design incorporates home
collection browsing. there have been disagreements about the relative
importance of this feature, and the prominence and placement of the
browser in the ui is still open to debate.

> > /error - error messages
>
> I'm ambivalent.  I thought there was already an /error mapping, so what
> would be different here?

nothing that i can see.

> Also, /feed -> /atom and /home -> /dav.  Brian's mention elsewhere, but I'm
> +1 on them.  I'm hoping to see the whole URL scheme in one place to look for
> places to rationalize it before settling the URL namespace design eventually.

right. /cmp would stay the same. /feed could also potentially become
/gdata - since gdata is really just a superset of vanilla atom, we can
send a gdata feed to a basic 1.0 atom client with no problem. then if
we ever support calatom or any other alternative atom-based protocol,
it will be a peer of /gdata.