[cosmo-dev] OOTB collection and iCal3

[Jared Rhine]

Brian Moseley wrote:
> Jared, can you calculate the number of people who access home
> collections by path rather than by uid (those requests whose uri-paths
> begin with /dav but not with /dav/users, /dav/item, or
> /dav/collection)?

It's somewhat difficult to put mush all that together down to "number of 
people".

But I've scanned through lots of logs after extracting /dav paths and 
taken away some impressions.

There are a number of iCal 3.x new-signup users getting bitten.  I'd be 
in favor of a patch to fix the creation of new default collections that 
use an underscore instead of space.

If there was a patch against 0.8 branch that did this during initial 
collection creation and was eye-ball verifiable as correct, I'd apply 
that patch to the Hub immediately without it being included in any 
formal Cosmo release yet.

I'm surprised at the number of iCal 3.x users.  I need to rework the 
metrics to split off that client now, for sure.

There are a number of users 2-5 a day who are getting to 
/dav/username/Foo%20Bar via the account browser (referer has /browse). 
Sometimes I can see those people proceed to put those in an iCal 3.x 
client or add tickets.

People have created some of their own collections (not the default) that 
have spaces.

There's a smattering (couple a day) of neon/command-line users.  Here's 
an interesting academic project log:

http://wiki.linuxcentre.net/index.php/Project
http://wiki.linuxcentre.net/index.php/Project:Info

There are a large number of regular Lightning users (it looks like) who 
are using ticketed /dav/username/uuid?ticket=blah forms.  Those would 
not be affected by the proposed retroactive rename, but do fit the query 
that bcm posed above, so worth noting.

I'm pretty torn on retroactive fixing.  I think if we fixed 
new-collection creation to not have spaces, the vast majority of our 
real-world issues would go away.

My overall guess is that perhaps 5 people would be affecting by changing 
their collections "from under them" to remove spaces.

I'm 100% for not creating a default collection with a space, ASAP (with 
display name as anything).  Does the proposal go further to ban creation 
of new collections (manually) with spaces in the resource name?  I think 
I'd be against that since it's a valid thing to want to do.

Is the proposal to change *all* collections with resource names with a 
space, or just the "first" one retroactively?  I supposed it's not 
trivial to figure out which collections should be affected if we're 
talking about a subset.  Essentially all users have at least 1 
collection with a space, though few users are accessing it currently.

-- Jared