[Kroupware] Kroupware RFC

[Bo Thorsen]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 13 March 2003 13:01, Stephan Buys wrote:
> On Thursday 13 March 2003 12:33, Bo Thorsen wrote:
> > On Thursday 13 March 2003 09:55, Stephan Buys wrote:
> > > Hi all,
> > >
> > > I was just wondering if it would be a good idea to create an
> > > official RFC around the collaboration features of Kroupware and
> > > Bynari.
> > >
> > > More specifically:
> > > Formalise a method for storing contacts, notes and calendar events
> > > in IMAP folders (ie. iCal encapsulated in MIME)
> >
> > I like this idea. That would make it a lot easier to ensure that
> > different kolab client implementations would work with the same data.
> >
> > > Another idea would be to store FREE/BUSY information in LDAP so
> > > that it becomes easier to look up this information in massive
> > > organizations.
> >
> > I'm not sure about the reason to do this. The clients can without
> > problem download this info
> > (http://kolabserver/freebusy/username.vfb). The problem is that there
> > currently is no way to see other peoples free/busy info without
> > making an invitation. The transport isn't the issue here.
>
> This was just an idea off the top of my head. The rationale behind this
> is that I dont like the "username.vfb" limitation. With an LDAP store
> it would be easy to query the LDAP server on a number of different
> criteria. I could fire off a search for the entry "My Attendee" and
> recieve a freeBusyURI attribute. This attribute would then contain:
> http://kolabserver/freebusy/username.vfb
>
> The current method has several limitations like:
> you have to know the exact format of the FREE/BUSY URI.
> If your client (like Outlook) uses an environment variable to retrieve
> the iCAL file then you are also limited to using special format
> usernames and filesnames for it to work. In my mind bringing LDAP into
> this just Makes Sense (TM)
>
> But that is just me :-)

No, actually you convinced me about this. It would be a good idea. I'm=20
especially thinking of those that belong in two different kolab groups.=20
They have a problem with the current scheme.

> > > This way it would be easy for other projects (commercial or
> > > non-commercial) to implement groupware functions that can
> > > interoperate with each other.
> >
> > Yes and that would be A Good Thing(TM).
> >
> > So, do you want the job of writing such an RFC?
>
> Hmmm. Maybe ;-P

Noone else have taken it so far... :-)

Bo.

=2D --=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+cHjimT99lwfUS5IRAkNhAKCurVCHJ4jajNR0sxcsqNZYRAIOBwCcCWZ3
sce32q1mKmLRuw6tGkXOg3k=3D
=3D402a
=2D----END PGP SIGNATURE-----