[kronolith] Re: Generation of user friendly FBURL

[Ken Weaverling]

This short thread has been valuable for me because it's given me some
insight into how free/busy works, but I still can't get it to work even in
the simplest case (I sent a msg to the list yesterday with full details).
I think I must be doing something wrong, from the user perspective, since
I don't understand it.

Right now I'm manually putting in the generated FreeBusy URL for each user
into the other users addressbook for them. Make appointments, the web
server queries for the info, and the info return (by doing many gets)
looks fine, but no free busy info shows.

Is it because I'm not using a public ldap right now to update? If that is
required, why is there an option for free busy url in the localsql "local"
addressbook people use? Or are people expected to make thier own
addressbook entry in ldap that keeps track of the freebusy URLs they want
to use. Does kronolith write back to the ldap to keep this current or do
people have to notify everyone who wants to make a meeting for them what
the changed URL is? Did the limitation ppl talked about last year of only
having one addressbook defined get addressed?

I have a new CTO and he's a bit shocked that we don't have any type of
shared calendar system now (we're one release behind on horde stuff now)
and since our new CTO came out of an exchange shop, he thinks we should
consider moving to that, but is more than willing to see what alternatives
are.

I had a tech, who used to do exchange in a previous life, set up a test
exchage server for him, and he (the CTO) showed me how scheduling meetings
worked. He had two users we created for him with no real settings beyond
the defaults, scheduled a meeting on one, went back to the second account,
tried to schedule, it display the freebusy info, and just worked. I assume
somehow that data is saved up to Active Directory.

Now I'm struggling with trying to figure out how to make it work with
Kronolith and can't figure it out. There's nothing in the docs, and the
archives don't cover much, except people having problems, then saying
their particular case was fixed.

Maybe some overview philosophy behind the thing would be helpful, or at
least a short blurb on the minimum things required to make this work
right (software components and user procedures).

Feel free to call me stupid, because that's how I'm feeling! :)

On Sat, 2 Apr 2005, Chuck Hagenbuch wrote:

> Quoting Kevin Myer <kevin_myer at iu13.org>:
>
> > 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
> > specialcase(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 don't think r for room is needed. Perhaps r for resource if they're
> not regular accounts or calendars, though (could a room really have
> more than one calendar?). But otherwise that sounds like it'd work to
> me. Patch? Enhancement ticket? What you wrote here is a good
> description/argument fwiw:
>
> > 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.
>
> -chuck