[kronolith] Re: Generation of user friendly FBURL

[Kevin Myer]

Quoting Chuck Hagenbuch <chuck at horde.org>:

>
> Well, we could start assuming Horde username now - probably a good
> idea. Of course you then have to decide if you just ask people for a
> username, or list users, or ...

Probably my idea is better expressed not as a request for a user friendly URL
but for a consolidated entity URL.  If I know an email address, or username, I
should be able to predict a FB URL.  It shouldn't matter if they have one
calendar that they keep their events on or four hundred calendars they keep
their events on.  For a person, you really don't want the FB URL to 
change.  Do
I want to notify all my contacts that they now have to use a different URL
because I changed my share id?  Or added a second share id that also needs to
be included to see if I'm really available?  Is someone going to be happy
because they used an old FB URL idea (which would still generate perfectly
valid, but incomplete FB info for me) and scheduled a meeting and then found
out I was really unavailable?  How do you maintain FB URLs in a corporate
setting if they have the potential to be changing all the time?

> But I don't think this is a good idea because it goes against being
> able to individually address calendars - think about conference rooms,
> etc; those should have their own free/busy info, and aren't necessarily
> going to be individual users.

Add a second (or third) case to fb.php.  Use that as a flag to switch between
the normal case of generating entries for a Horde user, and the special 
case(s)
of generating for a room, or other item.  Say use "c" the way it 
currently is -
the calendar share id, "u" for generating all of a user's FB info, and "r" for
a room, and that could actually just be a "c" for that matter, because rooms
wouldn't be likely to have more than one calendar (but maybe there would be
some other magic that need to be taken into account that would warrant a
standalone designation).

I'd be highly delighted to see conference rooms as something I could 
pull up and
reserve.  I can already see a Horde Locations class with hooks to LDAP to pull
in all your reservable locations, populate the New Event Location field in
Kronolith, click on Edit Attendees and your room is already included in the
initial required attendees list (or listed under the new Rooms portion of that
screen).

> This would also put overhead into free/busy calls that's not there now,
> and make caching tricky since you don't know what a given URL is going
> to result in anymore.

I'm not quite sure I follow that but since I didn't write the code, I'm not
quite as familiar with it.. :)  I can understand where some extra overhead
might come in, from one preference call but thats it.  I'm not sure why you
couldn't cache the results nonetheless.  Lets assume that two calendars are
what I want to use for my FB info.

A call to http://website/kronolith/fb.php?c[]=a&c[]=b generates two
generateFreeBusy calls and the results can be cached.

If you did something like http://website/kronolith/fb.php?u=username, 
this would
generate a lookup to the kronolith preference "fb_cals", which would return
share id "a" and share id "b", which would generate two 
generateFreeBusy calls,
which could be cached.  Only one additional step from above:  doing the
preference lookup for the share ids to be used for fb_cals.  And you should be
able to cache that result as well, based on user name, and based on 
share id. Someone needs just one of those entries in the near future - 
its in the cache. Someone needs both?  They're cached.  Someone needs 
all your FB info?  Its
cached.

> I'd rather explore being able to have friendlier names for calendars -
> either a user-pickable id, or being able to use the full calendar name
> to pass to fb.php. Or maybe using the share id, instead of the share
> name - that'd be nice and short. Still unfriendly, though.

I think having fb.php handle multiple cases would greatly enhance 
Kronolith. "c"
for calendar, "u" for user (which does a preference lookup to find which
calendars to use for that user).  I'd need to do one mass update of existing
LDAP calfbURLs but I'd never, ever need to change them again.  I can guarantee
you that if I create a calfbURL for a new user, you can come back tomorrow,
next week, a year from now, and use that URL and no matter how many calendars
that user decides need to be a part of their FB information, you'll get
accurate FB for them.  If you leave it the way it is, and the user decides to
delete their current calendar, the LDAP entry is obsolete (I use LDAP 
but thats
only an example - it doesn't matter where its stored).  If they create a new
calendar and want to include that in addition to their first default 
share, the
entry is obsolete.

I guess to me, the bottom line is this - relying on a FB URL that is 
subject to
potentially dynamic (in terms of values and quantity) variables doesn't seem
like a good idea.  I'd think you really want the FB URL for a user to be
static.

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717) 560-6140