About CalDAV

[Bernhard Reiter]

On Friday 07 January 2005 23:12, Helge Hess wrote:
> On Jan 5, 2005, at 11:30, Bernhard Reiter wrote:
> > First I would say it is an access protocol, not a storage format.
>
> Hu? You "could" say that, but this wouldn't make it more true. CalDAV
> is like IMAP4 a protocol to "access" a storage, yes. But CalDAV also
> defines the storage format to be iCalendar, just like Kolab1.
>
> > The storage format of a CalDAV server might be a database scheme.
>
> How is that important? The storage can also be an IMAP4 server. CalDAV
> is a protocol, not an implementation. Some will implement it using a
> RDBMS, some will using some BDB and some simplistic ones will use plain
> files. Same like with IMAP4 servers.

See my other email about this,
I expect real implementations to rely on fat servers.

> >> Interoperability is something as (more ?) important as efficiency :)
> >
> > The question is: Where do you need interoperability?
>
> If you don't need interoperability nor want to reuse existing
> technology, you don't need standards, thats right.
>
> Personally I need interoperability so that one must not write a special
> connector for each and every server for each and every client. Thats
> completely stupid waste of time, especially because _all_ OpenSource
> clients already are based upon iCalendar internally.

That is you personally, but we go a different approach
with interoperability where needed: Data exchange and 
communication with people external to your own groupware
and use the storage to improve the solution.

Note that if you count all the Free Software groupware solutions,
many web-based solutions will not use iCalendar internally,
AFAIC the exchange4linux server also does not uses a database.
From understanding your explanation opengroupware uses
a database, but additionally saves iCalendar, is this half based
on iCalendar internally?

> > Some places from
> > http://greenbytes.de/tech/webdav/draft-dusseault-caldav-01.html
> >
> > where design differences can be seen:
> > | The HTTP/WebDAV feature model encourages a wide range of clients,
> > | from extremely simple to very rich.
> > | This is because servers must support a wide range of features,
> > | but clients can pick and choose which features to support.
> >
> > Kolab shall scale well and be secure which conflicts
> > with complex server operations.
>
> Where does it say that server operations are complex? It says that
> clients can be rich in functionality, the paragraph doesn't say
> anything about the complexity of server operations.

I think the chance is high that most implementation will go this way,
see my other email about the design phlisophy differences.

> Notably Kolab clients also required a wide range of "extra" features in
> the IMAP4 server - so many that they are hardly interoperable with
> arbitary IMAP4 servers and only work against Cyrus imapd.

The extra features are minor and do not hurt scalability.
All IMAP servers are improved over the time and they are easily
added to other imap servers.

> > | Many WebDAV working group members are discussing more work
> > | to improve the performance of synchronization betweeen WebDAV clients
> > | and WebDAV repositories.
> >
> > This sounds like they are working on inventing a network filesystem
> > again
> > with special properties. The Kolab server was build on disconnected
> > imap
> > which already has server implementations providing a very good speed,
> > thus is a step further down the line where WebDAV needs to go for
> > offline usage.
>
> I would like to learn about features offline IMAP4 provides which are
> not in HTTP/1.1.

I think the thread with Martin has some of the details,
though probably you can also make it work with HTTP/1.1
and extensions.  We need to wait for the implementations bringing
it all together.

> The work being done in WebDAV "to improve performance" is work on
> transmitting only diffs of a single entity. AFAIK IMAP4 provides
> nothing like this.
> (personally I don't think that this is relevant for CalDAV though, its
> more an issue for synchronization of repositories containing large
> files)

Both true and because of the latter we do not need it for Kolab
and using IMAP4 is okay.

> > The good part about the two contracts sparking Kolab was that
> > there should be a usable solution that is ready for production usage.
> > It keeps us on the ground so we create a solution that works first.
>
> Yes, that is certainly a good approach and I agree that CalDAV somewhat
> lacks that and might be doomed to fail due to this just like CAP. Time
> will show, OSAF seems to be very focused here.
>
> > Standardisation works better if you have a few good solutions to look at
> > and not having a comittee thinking about how they should work.
>
> Thats where your argumentation fails. Because the current approach of
> Kolab2 provides _no interoperability at all_ and is just a _single_
> solution which focuses on "the task at hand", not on interoperability.
> Actually the choice of technologies is so limited, that it doesn't even
> work with arbitary IMAP4 servers.

Both points addressed above.

> They correct way is somewhere in between, IMHO. Yes, you need a
> practical setup which is supposed to work, but you also need more than
> one server and client to accomplish interoperability. And think about
> that up front.

I agree that a good way lies in between, we thought about this before hand
and did it this way as I explained for both point earlier in this email.

> > There are not that many Free Software groupware solutions
>
> Freshmeat only lists 280 projects in the groupware category. There are
> LOADS of free groupware solutions.

I was thinking from the user perspective for larger installations
and wanted to imply more than just the software.

> One of the issue which IMHO hurts most is that few of them provide free
> groupware client connectivity (like Kontact or Evolution). And this is
> IMHO due to a lack of a reasonable easy standard for doing calendaring.
>
> > and none of them has taken a huge international market share for
> > larger installations.
> > Kolab has the potential to grab a larger share,
> > not in spite of but because of our XML storage format!
>
> Good look! At least you have a very good reference client ;-)

Other reason could be that they do not scale that well and to not
offer a good Outlook connectivity.  Kolab addresses both.

Best,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20050114/7fd80273/attachment.p7s>