CalDAV - the open groupware protocol
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 70 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39502 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Collaborative softwareCommunications protocolWebDAVClient (computing)Open setServer (computing)Time evolutionStandard deviationStack (abstract data type)Linear programmingMoving averageSanitary sewerPlastikkarteContent (media)Polygon meshLemma (mathematics)ArmSummierbarkeitHierarchyHost Identity ProtocolForm (programming)Key (cryptography)Operator (mathematics)1 (number)Fitness functionNatural numberContext awarenessGroup actionBitQuicksortOpen sourceLine (geometry)MultilaterationMereologySpacetimePurchasingMultiplication signImplementationFilm editingModal logicSystem callInformationNumberTerm (mathematics)EmailOffice suiteRing (mathematics)WritingData storage deviceForcing (mathematics)InternetworkingScripting languageCommunications protocolMetreMathematical optimizationMathematicsCASE <Informatik>Execution unitClient (computing)AdditionAddress spaceEvent horizonRight angleSoftware developerRevision controlRepetition19 (number)Category of beingContent (media)Axiom of choiceMatching (graph theory)EvoluteDisk read-and-write headLattice (order)Network topologySet (mathematics)Video gameCountingFile formatServer (computing)Collaborative softwareComputer fileStandard deviationLatent heatWeb 2.0Condition numberFörderverein International Co-Operative StudiesUser interfaceUniform resource locatorConnectivity (graph theory)SubsetHierarchyException handlingUniformer RaumIntrusion detection systemUniqueness quantificationComputer animationLecture/Conference
09:13
HierarchyWebDAVComa BerenicesImplementationGroup actionPrincipal idealClient (computing)ExplosionHardware-in-the-loop simulationPointer (computer programming)Server (computing)User interfacePhysical systemGame controllerCache (computing)Extension (kinesiology)Software developerAddress spaceTraffic reportingElement (mathematics)Computer fileUniform resource locatorClient (computing)InformationEvent horizonGroup actionWeb 2.0Dependent and independent variablesMultiplicationRepresentation (politics)Different (Kate Ryan album)Category of beingSet (mathematics)Communications protocolAdditionDirectory serviceImplementationSubsetStandard deviationNetwork socketQuery languageOpen sourceStapeldateiWeb browserBasis <Mathematik>Interactive televisionFile systemCASE <Informatik>Operator (mathematics)Error messageLatent heatCovering spaceContent (media)Principal idealCycle (graph theory)Interface (computing)RepetitionSpacetimeFilm editingContext awarenessDecision tree learningMaxima and minimaAbsolute valueCartesian coordinate systemTorusData storage deviceCanonical ensembleSinc functionProduct (business)NeuroinformatikLine (geometry)Open setState of matterPoint (geometry)DatabaseConnected spaceCAN busTablet computerPresentation of a groupOffice suiteComputer clusterLecture/Conference
18:21
Query languageRegular graphCommunications protocolData typeType theoryTwin primePower (physics)Client (computing)Server (computing)Open sourceBroadcast programmingEmailScheduling (computing)ScalabilityProxy serverCache (computing)Overhead (computing)File Transfer ProtocolWeb 2.0Operator (mathematics)Group actionDigital photographyEvent horizonHacker (term)Absolute valueScaling (geometry)Maxima and minimaSoftware testingTraffic reportingPhysical systemProper mapRegular graphCache (computing)Client (computing)Interactive televisionServer (computing)Process (computing)MereologyReal numberMessage passingMultiplication signEvoluteEmailComputer fileCartesian coordinate systemStructural loadQuery languageStandard deviationScheduling (computing)Content (media)Type theoryCommunications protocolUser interfaceLotus NotesLattice (order)ScalabilityResultantLatent heatDependent and independent variablesIntegrated development environmentModule (mathematics)MathematicsDirectory serviceScripting languageOpen sourceTwin primeSurvival analysisLine (geometry)RepetitionCASE <Informatik>TwitterQuicksortNetwork topologySpeciesSound effectShooting methodHexagonDifferent (Kate Ryan album)Water vaporText editorSpacetimeConstructor (object-oriented programming)PlanningPatch (Unix)Active contour modelPurchasingData storage deviceFilm editingBitPoint (geometry)System callContext awarenessWebsiteImplementationComputer architectureWeb pageForm (programming)Data compressionConnected spaceNumberLecture/Conference
27:29
ScalabilityProxy serverCache (computing)Overhead (computing)Server (computing)Extension (kinesiology)SynchronizationLimit (category theory)Sanitary sewerUniform resource locatorPlastikkarteEmailCollaborative softwareOracleAbelian categorySoftware developerJava appletElectric currentStandard deviationClient (computing)Communications protocolServer (computing)Open setGroup actionPlug-in (computing)Software developerDifferent (Kate Ryan album)ImplementationPhysical systemMIDITestbedEmailJava appletExterior algebraBeta functionComputer programmingAffine spaceProjective planeLatent heatEvent horizonMathematicsWeb 2.0Product (business)Data compressionOpen sourceOperator (mathematics)Connected spaceExtension (kinesiology)CASE <Informatik>WordRecurrence relationComplex (psychology)Traffic reportingBitDatabase transactionSet (mathematics)Row (database)InformationCodeFunctional (mathematics)StapeldateiMereologyPurchasingSystem callFilm editingOverhead (computing)Equaliser (mathematics)Object (grammar)QuicksortProcess (computing)ComputerBoss CorporationSoftware testingGoodness of fitGraph coloringRepetitionCompass (drafting)Petri netProgramming languageArithmetic meanModal logicDigital electronicsEvoluteWeightNetwork topologyProfil (magazine)Address spaceCycle (graph theory)Term (mathematics)Multiplication signLecture/Conference
36:37
Electric currentTask (computing)Online helpProper mapAnt colony optimization algorithmsTime evolutionAddress spaceWebDAVMobile WebSynchronizationClient (computing)Open sourcePlastikkarteCore dumpCache (computing)Computer wormUniform resource locatorSoftware developerPlug-in (computing)Client (computing)EvoluteWindowProjective planeAddress spaceWeb 2.0Front and back endsGroup actionServer (computing)MereologySheaf (mathematics)Open setUniform resource locatorLibrary (computing)Java appletFunctional (mathematics)Object (grammar)AdditionInternet service providerParsingParsingBookmark (World Wide Web)Extension (kinesiology)Information retrievalFlow separationFile formatDependent and independent variablesQuery languageOpen sourceMobile WebCore dumpRevision controlMultilaterationScalabilityDebuggerSet (mathematics)Electronic visual displayModule (mathematics)Computer fileImplementationRegular graphReal numberCartesian coordinate systemSynchronizationStapeldateiEvent horizonPower (physics)Observational studyComputer configurationCommunications protocolMultiplication signPlanningCodeOnline helpInsertion lossContext awarenessUsabilityEndliche ModelltheorieSoftwareGraph coloringQuicksortGame theoryProcess (computing)PurchasingInterface (computing)HierarchyLecture/Conference
45:45
Computer configurationCategory of beingSet (mathematics)Computer fileBitCore dumpGreatest elementPasswordServer (computing)Gastropod shellPlanningStress (mechanics)Scripting languageOpen sourceCausalityLecture/Conference
47:01
Client (computing)BitElectronic visual displayPhysical systemComputer clusterComputer-assisted translationFunctional (mathematics)Content (media)Moving averageForcing (mathematics)Server (computing)Event horizonScalabilityAddress spaceTerm (mathematics)Dependent and independent variablesWater vaporPoint (geometry)Group actionPhysical lawSheaf (mathematics)File systemObject-oriented programmingComputer fileRegular graphCuboidComputer iconRootLecture/Conference
49:52
Standard deviationClient (computing)Time evolutionEvoluteRAIDServer (computing)CollisionSoftware developerOnline helpConcurrency (computer science)BitOpen setMultiplication signScheduling (computing)Group actionSuite (music)Software testingClient (computing)Library (computing)EmailStandard deviationWebsiteLink (knot theory)HierarchyMereologyGoodness of fitOpen sourceSystem callElectronic mailing listINTEGRALComputer iconWater vaporQuicksortRobotRight angleNeuroinformatikSelf-organizationLetterpress printingImplementationProper mapSurfaceLecture/Conference
54:13
Computer animation
Transcript: English(auto-generated)
00:07
I'd like to give a small talk about calduff, which is a calendaring protocol, actually about calduff, cardduff, and webdev. And it's mostly intended for open source developers because I want to motivate them
00:22
to implement those protocols. So actually I will give a short overview of the protocol itself. I'm talking a bit about the implementation which exists today. I want to say a bit about how to write a calduff connector.
00:40
So if you're a developer and want to provide a calduff client, I give some hints on how to work on that. And, well, related to that, how I think you can help with getting better calduff support in open source clients. So, as I said, calduff is a simple
01:01
HTTP-based calendaring protocol. It's a standard since last year. It basically describes how any groupware client, like, for example, Thunderbird or Evolution, can talk to a server system, like, for example, eGroupware or OpenGroupware
01:21
or Sarafa, of course. And another important thing to keep in mind is that calduff is just a transport protocol that doesn't describe how the actual data is formatted. For the actual data, the iCalender and vCard formats are used, which are in a standard
01:41
since, I think, more than 10 years. And the important thing is that all the open source clients which exist today, like Evolution, Mozilla, Sunbird, and Contact, are all internally based on iCalender and vCard. So it's a very natural fit,
02:00
and this is why I don't like articles like that. You can read that for Contact or for Evolution. So there are announcements like Contact or Evolution support Microsoft Exchange, and, well, it's very annoying because they do not yet support open standards,
02:23
but they put work into supporting Exchange. I can't understand that, especially because the clients itself are based on the data formats also used by calduff, so it would be very easy.
02:41
A bit about the protocol. Actually, the whole stack is pretty complex, but you usually don't need that because calduff also targets web interfaces, so it has a lot of operations so that web interfaces can directly talk to a calduff client. That's not something I'm talking about today.
03:02
I'm mostly interesting on what needs to be implemented in a native client, like a KDE client or a Genome client. They need much less operations. In fact, we have a small subset of that defined in the so-called group dev standard.
03:21
It's not really a standard, it's more like a document which contains the interoperability issues. I'll show that later. Well, to the parts, iCalender is very common. Most developers probably know how that works
03:40
because, as I said, it's used in the open source clients anyways. It's very simple text-based format which contains the necessary information. Nothing particularly impressive. The same goes for vCard, which is almost the same format except for contact data like telephone numbers
04:02
and email addresses and stuff like that. You can store birthdays in vCard. Wow, and the most important protocol for calduff is HTTP because almost everything needed to write a client service team
04:22
which does calendaring is already contained in HTTP. It provides operations to retrieve items, to store items, to delete items. Well, and it's actually, there's a new buzzword for that, which is REST, which just means that HTTP is applied
04:43
as it was originally intended, which is using those operations instead of using just post and some CGI scripts which do other stuff. So, this is how the HTTP looks like. So this is for retrieving an item.
05:01
You just use a get method to retrieve a URL which contains an event in this case. The if-no-match is actually an optimization. The number behind that, it can be anything. It's just a marker which says
05:20
whether the item changed on the server. So if the client retrieves such a calendaring event from the server and stores that into its own cache, it can put that version into the request and the server will only return the content if it actually changed.
05:40
So it's much faster. In this case, it changed and it actually embeds, it's a bad example, it didn't change, but it actually embeds an iCalender file and gives a new ETag. In this case, it's the same. Changing an item relies more on the if-match header
06:06
because the put operation is used for both, for changing an item and for creating an item. And in addition, a put operation, a write operation, must detect changes by other users.
06:20
For example, if another user moved an appointment in his client, another user must be able to detect that so that he doesn't overwrite the changes of that other user. And this is what the ETag is used for again. So this basically means only writes this content if it didn't change.
06:40
So if it changed in the meantime, the server will issue a special HTTP status code, which is 419 conflict, and the user can then decide whether the client should reissue the same request without the if-match or whether it somehow retrieves updated information and merges them or,
07:02
well, whatever choices the client gives the user. As I said, creating the item is basically the same thing. But to ensure that the event does not yet exist at that URL, you put that if-match star into the header.
07:22
This means that this request will fail if the meeting ICS file already exists. In this case, the client needs to issue a new, well, file name for that event and retry the request.
07:40
So most clients actually use unique IDs for that, so it's very rare error. Well, and final delete, it's also very simple. If you want, you can also add an ETag condition so that the delete only succeeds if no other user modified the event in the meantime.
08:04
Now you can also remove that and the delete will always succeed. Well, what we have seen before is just regular HTTP. It's in the standard HTTP specification and available for a long, long time. And the same is true for WebDAF.
08:21
It's quite available for a long time now, and the most important thing WebDAF adds to HTTP is hierarchies. So HTTP itself, a URL, a uniform resource locator, and the HTTP request is already kind of,
08:41
forms kind of a hierarchy. The components in the URL can be split by slashes, but the important thing is that there is no HTTP operation to discover which children such a collection has. For example, if I want to know that the developer's folder
09:03
contains a calendar and tasks, sub-items, there is no HTTP operation to find that out, and this is what the prop-find is for. It's the addition by WebDAF. Another addition is that WebDAF has a concept of metadata, they're called properties in WebDAF.
09:22
So by using the prop-find, you can also discover stuff like when got the file modified, what is the ETag and other stuff. It's also the basis for WebDAF extensions. It has a few other things like, for example, lock which allows you to lock a collection for modification, but that's not really necessary
09:43
because as we've seen before, HTTP already supports optimistic locking. So you can just attempt to write and it will only fail if it actually changed. So it's usually much better for the user instead of locking the whole collection.
10:02
So that's what it looks like. It's a prop-find operation which goes to a calendar in this case. And the prop-find instructions are contained in the body. So get ETag, this says that we want to retrieve the ETag of all items contained in that calendar.
10:23
And it always returns such a multi-status response which is basically an XML representation of multiple HTTP responses. So in this case, the ETag is returned and then always embeds the thing in such a response
10:41
element which contains URL to the item which is below that collection. In this case, calendar and some item, it's just a unique ID. The user usually doesn't see that. What else? For calduff, just below calduff,
11:00
there's also another extension to web.dev which is web.dev ACL, that's access control. So most important for calduff are so-called principles resources. Principle resources are just a standard for representing an account in a calendaring system.
11:22
So you actually get an URL, for example, principles, user is Helga, which represents that account. And this URL can be used to retrieve some information about that user. Usually those principle resources are not stored in some file or something like that,
11:40
but they are usually backed by some directory service, for example, ADAP. So for example, the Apple implementation uses open directory to store the actual principle information. But it's not just individual users, it's also groups and resources like rooms, which can be presented by principle resources.
12:03
The most common use in calduff is that the so-called calendar home set property. There's the same thing for address books, which is called address book home set. And the way it works is that you do a prop find on the principle URL and you get back those two properties
12:23
and they contain the URL, which points to the server, which provides the calendaring and address book services. This is pretty nice because it allows you to scale very well, so it can distribute users to different servers, you can use different servers
12:41
for address books and calendars and stuff like that. Well, it's about ACL. It also does a lot of commission thing, but that's not really relevant in calendaring that much. It's an extension. I really want to have open source developers
13:01
to implement the basics first. So calduff, as I said, requires most of those protocols. If you want to do a full calduff implementation, you would actually have to implement all those protocols or all those standards. In practice, almost no server does that.
13:20
Most servers just implement the subset, which is actually required to derive the Apple ICHI client because this is the most known calduff client and more or less a standard to test the calduff features. But I come to clients later as well.
13:41
calduff, just one additional HTTP method, which is introduced in ACL, actually, but it's also used in calduff, which is called report. It's pretty similar to the prop-find, but it's a way to extend the protocol. So report, request is in the body.
14:03
Well, because native clients, which run on the desktop computer, usually keep a cache for offline information and stuff like that, we do not really need the report because all the queries, like give me a week of appointments or find a contact with name hello world,
14:22
are done on the client, not on the server. This is something which is important for web clients. For example, a web client could ask the server to return just a week of events, but for native clients, it's usually a useless feature because they have their own cache and do the queries in the cache.
14:41
There's one report which is very useful, and that's a so-called multi-get report. When you synchronize a server the first time, and for example, it contains a thousand events, what happens is that the client issues a prop-find, it discovers the thousand event URLs,
15:01
and then goes on to fetch a thousand, or does a thousand request, get request, to retrieve the item. Actually, that's not that bad as it sounds because HTTP 1.1 also supports pipelining and persistent connections, so issuing a thousand request
15:21
isn't as slow as one might think, but still, especially in database-based servers, a multi-get can give performance advantages. It basically says that in the multi-get report, you can specify a set of URLs, and you get, for example, 50 events in one batch
15:41
by just issuing one HTTP call, so it can be a major performance improvement, but for example, I'm also testing against Apache, which doesn't implement report. It's very fast with get as well because it just pulls out the files from the file system and puts it on the socket.
16:01
It's very, very fast. Could we do questions later, please, or? You seem to be just wondering about the servers. You seem to be dismissing the server with no servers do everything. As a server developer, it would be nice to know where to look. Exactly, and I come back to that later. It's actually a thing we want to document in group def
16:22
because we think that group def is a subset of all those specifications which are needed to implement a client system. Everything else can be done on demand. For example, you can issue a report. If it isn't implemented, you get back an error code,
16:40
but I show that. Let's wait a minute. That's something I actually wrote just below, so why you can use a calduff report to retrieve a bulk multiple events in one step. If the server says he doesn't support that, you can still fall back to get.
17:00
It's not a lot of work for the client developer to do that because it's just an optimization. And the important thing is that this get is, again, plain HTTP, so it works with servers which do not implement full calduff or that particular report. As I mentioned, there are a lot of different reports.
17:23
You can extract just subsets of the iCalender file and stuff like that which are interesting if you want to write a web interface which directly interacts, using the browser, interacts with the web server, but I've never seen that, and I think it's pretty useless, actually.
17:43
calduff is basically the same like calduff, just that it's for contacts. The contacts are stored in vCards. There's also such a multi-get report, but in any other way, it's the same thing like calduff, just for contacts, so it's currently still in development.
18:03
Well, actually, Cyrus Taboo is a guy who has written the draft, but I expect that this will be standardized during 2009, probably in July or something like that. So here we are coming to group def. With group def, we try to formulate
18:24
the absolute minimum of operations which are necessary to maintain a proper client cache so that a native client can be developed which interacts with such a group def server. The reason is that, well, as I said,
18:40
calduff and even web def itself is pretty complex if you want to implement it. Very few people actually implement the photo specification, but group def is super simple. It's not even requires you to implement all of web def. If you do, it's great because you can use regular web def clients, but a real group def client can operate with,
19:03
interoperate with much simpler servers. So it's just one prop fine query which we specified in part of that group def document. I am showing that later on. And as per a group def specification, you are not allowed to issue different prop fines.
19:21
This way, it's 100% compatible to web def and calduff. So every group def client is automatically a full web def, well, a calendaring web def client and can talk to any calduff server because any calduff server by specification implements those things. Otherwise, it's just same thing
19:40
like get, put, delete, everything plain HTTP. Content types are vcald and icalender. Folder discovery is used using the prop fine. So in the results set, you get responses for the folders. We actually need to take calender folders with a special type so that the client knows
20:01
that this folder is a calender server. Well, the cool thing, or in my opinion, the coolest thing is that you can, you do not need a group server at all. You can use just Apache web def support. You just need to enable the web def module
20:20
of Apache and you can use to store that in group environments. And it's not fishy or something. It's properly protected using the e-text or congruent edits and all that work.
21:24
Disadvantage, okay. Now it works. Okay, great.
21:43
So the only real disadvantage is that, of course, you do not have a web interface or something like that. So it actually only works with real clients. So it isn't too difficult to write a small script or something which watches Apache directories for changes and just generates appropriate
22:03
HTML files for that. You can do that using fire system callbacks and just generate a web interface aesthetic one which is very scalable. Yes?
22:27
No, not a cal def client, a group def client. You could use any group def client. The cal def client, or most on the market, like for example, iCal, really do use those report operation, for example, and have no callback.
22:42
A group def client could also attempt to use a report but would fall back to prop find and the regular operations. But I also talk about the implementation, so I'll come back to that later. Maybe check the time as well.
23:01
Okay. In my opinion, it's very cool, because everyone has an Apache web def. It's included in the latest releases and it really works great. It's very fast, even for larger collections. It doesn't scale to 100,000 events in one folder, but for regular use cases, it's pretty nice, actually.
23:23
So group def, as I said, is for offline clients only. We do not provide operations which are necessary for web interfaces, like give me just one week of events. So we actually assume that the local client keeps a cache of the item to retrieve before,
23:40
because otherwise it would always need to retrieve all events. It wouldn't work. But group def clients, yeah, well, local clients need to keep a cache locally anyway, because you want to have offline capabilities. So it's not really an additional requirement. As I said, it's very simple, especially for the server vendors as well,
24:02
because they only need to implement that single prop find and the get and put operation, so it's really easy. And it also has a few hacks. We had added, we documented a few hacks which can be used to better support database-based servers,
24:20
like for example, e-group fair or open-group fair. Test to do with the UI constructions, but I do not really have time to go into detail. On top of Cardiff, the committee added another specification, which is Cardiff scheduling. That's basically the same like IMVIP,
24:42
which is used to exchange invitations. For example, if I'm your user and I want to invite another user to a meeting, I would, my mere client, like Evolution and Contact, almost anyone supports that. They send an iCalender message embedded in a regular MIME mail to the other user,
25:04
and you can then accept the meeting, and all the interaction in that is documented in itip and imip, standard protocols which are widely deployed and standardized since a lot of years as well. And Cardiff scheduling is almost the same thing,
25:23
just over HTTP. Well, if you are a client developer and you want to start adding group dev support or Cardiff support to an open-source client, please do not look into that. Yeah, it's quite complicated and it doesn't really buy you with that much
25:42
because the IMIP also works perfectly fine with calendars stored in Cardiff, so you can just exchange invitations via email, which is completely standard. Even Outlook and Lotus Notes support that quite well. Not perfectly, but quite well, so you can actually interoperate
26:01
with those people in scheduled meetings. But we'll see. Scalability, I talked about that a bit before. Of course, especially a group dev system with a local cache is really scalable because it has that cache, it does all the operations in that cache,
26:22
and doesn't need to call the server to perform operations like, well, sorting events or search for context, so the actual processing work for searches is put on the client, so it's quite fast. Due to the architecture, because it's based on HTTP, it's really super scalable.
26:41
You have all the features of HTTP which are used to make websites scale. And actually, the events which are transferred by Cardiff, the files are much smaller than an HTML page, so you can actually use caches like Squid if you have a really large system to reduce the load on the application servers,
27:02
and use ETags with that, because if the cache has the ETag, he knows whether the cache needs to retrieve the file from the backend server, so there are a lot of features which make that very scalable. Well, as I said before,
27:21
HTTP also supports persistent connections, so issuing a lot of requests isn't that bad as it sounds, but most importantly, HTTP itself also supports compression, so it's not so important for the events if they are transported because they are quite small,
27:40
but the XML of the prop find can become quite big. I put some numbers, roughly, so a thousand items produce an XML which is about 200K, which is quite a lot, but because the XML is so rare both, it also compresses very well, so if you enable gzip compression in the client,
28:04
it just comes out as 12K, which is quite okay, and well, even for 10,000 events, which is quite a lot for a single folder, it's just, well, it's not just, it's more, it's 130K, which is significant, but acceptable, in my opinion,
28:22
but most extensions which exist to that protocol are trying to improve the situation with the XML overhead, and especially Apple is doing a lot of work on that as a Darwin epic calendar server, which is completely open source,
28:40
and it's written in Python, and more or less acts as a test bed for features. Developer of the Apple server is Cyrus Taboo, which also worked on the calduff specification and for the calduff specification, and before he puts those into specifications, he usually implements that in the Apple server,
29:01
and for reducing the prop find overhead, there are actually two things. The one thing which is already in production use is ctechs, ctechs are like etechs, and etechs says whether an event has changed by some other users or by some other means. It's ctech is roughly the same, except that it covers a whole collection, a whole folder,
29:24
so if anything in the folder changes, the ctech changes, so the client can check for the ctech, and only if it changed, it does a full prop find. The nice thing is, again, if you write a calendaring client,
29:40
you can check for the ctech, and if it doesn't work, you can still do the regular prop find, so it's very easy to fall back to basic functionality if that's necessary, and very new, it just got into the Apple server trunk a few months ago as Java-based PubSub.
30:01
That's a way to let the server inform you about changes, so it's actually an information trigger, a notification trigger by the server if something changed in the server, so the client only needs to do the prop find if something actually changed,
30:20
and that's awesome. Everything standard space, it's Java, and if it isn't available, the client can just fall back to ctechs and to regular prop find in the second row. It's really not bloating the code, actually. Well, and all the extensions, you can actually look at that. It's written in Python.
30:42
It's okay to read and available from Apple. There are a set of known issues, but most issues, if you talk about calduff and carduff, are not related to the protocols. It's usually related to the data format,
31:01
which is iCalender or vCard, because especially iCalender can be quite complex. For example, if you have recurring appointments and stuff like that, you can, in iCalender, you can build pretty complex recurrence words which are not supported by any client, but in the case of open source calendaring clients,
31:21
it's no issue if you want to add calduff support because those clients are based on iCalender and vCard anyway, so the developers of Mozilla, of Evolution, and of Contact already did all the hard work of doing the iCalender implementation, for example. The best iCalender implementation has contact, I would say.
31:43
There are a few other issues, but you are not really hurt by that in practice. We can talk about that if you run into that. It shouldn't be a hurdle. Okay, I want to tell a bit about the implementations. That's about the situation mid of last year.
32:04
There were those group dev effort which I started personally at the end of 2004. There are about a few smaller vendors which support that, like open group fair, citadel, and e-group fair. There was a work on the calduff standard,
32:20
which was mostly done by, or was done by Oracle, by Apple, and also beta work, which is an educational calendaring system. It's written by an American university. But really, the huge amount of group fair system, open source group fair system,
32:40
just invented an own protocol for their needs. So for example, if you have contact, you have something like, I think, 10 or 15 different plugins which can connect to the group fair servers. And, well, right now I think in fresh meat there are over 400 different group fair systems listed.
33:01
So it can't be the solution. But surprisingly, in last year, the calduff really got adopted by a huge amount of vendors. That's mostly because everyone, for some reason, wanted to support the Apple iCal client. And the Apple iCal client
33:21
only used the calduff protocol, which they probably put into an RFC. And so there was a, it's the first time, and as far as I know, that so many calendaring server vendors agreed on a single specification. So all of them either support full, well, partial calduff necessary
33:43
to direct the iCal client or group dev. But it's really a lot. For example, e-group fair also implemented group dev, but there are really a lot of projects which are doing that, and I expect that this will be the standard, like IMAP, for example, is for email.
34:01
Even Google and Yahoo support calduff for calendar access last year. You can access a Google calendar using calduff. So, because there are so many implementations, I thought I should suggest some. It's mostly, all of them are pretty good,
34:21
but it's usually the developers have some affinity with the programming language. There's a dev iCal, which is written in PHP. I think it's actually a standard package in Debian as well. There's a Darwin calendar server, that's the Apple one, which is written in Python. There are scalable OGO, which is written in Objective-C.
34:44
Beta work is that educational server, which is written in Java. There are a lot of alternatives to that. You can just browse freshman and find probably about 10 Java servers which are doing that.
35:00
Sorry? Apache? As a group fair server, a group dev server. For example, the Apple iCal client is not a group dev client because it uses extended calduff methods. So, to connect Apple iCal,
35:22
you actually need a lot of calduff operations. But, well, I come to the client implementations later on, but for clients which are advertised as calduff clients, you usually can't use Apache web dev.
35:40
But I come back to that later. And I would like to have that changed. Actually, if they are developers from the client project, that's basically my, well, what I would like to see is that they can probably fall back to group dev so that Apache is supported. Well, if someone knows, a Ruby one, tell me.
36:02
Write me an email. Well, as I said, I would suggest one of those servers. Well, my personal favorite, as I said, is Apache web dev. And I've put a lock of such a Apache transaction
36:21
which shows how the fallbacks work. For example, the client in this case first tried to perform a report to fetch multiple events in one batch. And it gets a 405 return code which says that that method is not implemented.
36:40
And the client falls back to just retrieving the individual events. And as you can see on the timestamps, it's pretty fast. Even if the next batch attempt starts, it's really fast. It's like, I don't know, two or five milliseconds to retrieve an item from the server.
37:04
And actually, well, I come back to that later, Evolution, and there's an implementation for Outlook. But I would really like to see that in all open source clients. To the implementation, client implementations, first there's contact. We actually implemented a group dev in contact
37:23
together with some KDE people. And end of 2004, we actually also specified that group dev during that session. It took about two days or a weekend. Well, the problem is that KDE just rewrote
37:43
all their infrastructure. So they brought a new client library which is called Akonadi. And it will be used in some later contact versions. The contact still doesn't use that. And it doesn't provide any support for web dev yet.
38:00
So it's quite crappy. But we really hope that we will be able to change that. Probably if contact is ported to Akonadi, we will have a development session with the Akonadi developers to add web dev, group dev, and cal-dev support to contact.
38:22
I hope that we'll be able to do that until the end of the year. The second one is Evolution, of course. We also provided a group dev backend, or group dev plugin for Evolution. It was a Noodle project that was sponsored by Junta de Andalucia in Spain.
38:42
Unfortunately, it didn't really pick up at this time. So the connector just became unused, unsupported, unmaintained, so it can't be really used today. It's still in the CVS repository, but it's not really useful. But Evolution actually has reasonable web dev support.
39:03
For one, you can configure cal-dev calendars. So you can use cal-dev, together with a real cal-dev server, but it doesn't provide group dev fallback. So Apache, for example, doesn't work as a backend for Evolution. But Evolution actually supports plain web dev address books.
39:23
So you can store a set of contacts in vCard format on an Apache web dev server, and Evolution can probably display them, edit them, and it works very, very well. So it's quite good. So, I'll show it a bit, collection browsing.
39:41
Okay, so this is a dialogue of Evolution for adding a web dev address book. The thing which I do not like about that one is that you need to specify the URL to the actual address book collection. What I would like to see is that you just enter some URL
40:03
and then will be able to browse through the server, like in a file browser, because that's what web dev is all about. It supports hierarchies, and you can browse through them using the appropriate pop-front requests. So actually, if there's an Evolution developer,
40:21
please add a browsing module which allows you to select the address books on the server you want to subscribe. That would be much nicer. But even this address book is pretty nice. I just discovered that about two months ago, and it's really working very, very well. And as I said, it supports Calif.
40:42
Well, it's a panel for adding Calif. It basically has the same complaint. You can browse the server for calendars, but otherwise it works quite okay. So it's quite usable. But as I said, you need a real Calif server. And finally, Mozilla, the Mozilla Alliance,
41:00
which are Sunbird and the Lightning module for Thunderbird. They are actually very good, because first, a few of the Mozilla Sunbird developers actually work on Calif implementation. So it's unlike an Evolution or a Contact, the core developers are actually into Calif
41:21
and support that. So there's a lot of work on getting that working well. And in addition, there's a scalable OGO project, which is just another group fair server. And the scalable OGO project provides plugins for Mozilla.
41:41
So it's just regular Mozilla extensions. And those extensions are not specific to scalable OGO. They are real group dev clients and real calendaring service extensions. So it's quite good. And it's also very easy to hack. In the address book, for example, it also misses the collection browsing again.
42:03
So you can't actually browse a server for address books or calendars. What other clients are there? First, there's a Funnambool group dev plugin. Funnambool is a synchronization server which can synchronize web dev servers with mobile devices.
42:22
So it's a Java application server. And there's a plugin for that, which is a group dev plugin, which can basically synchronize a group dev backend with any mobile device supported by Funnambool. Personally, I haven't tried it, but I'm told that it works.
42:40
There are other clients. Mulberry, for example, I don't like the user interface, but it's actually a pretty powerful caldiff and imap client. There's Chandler, which is by the Open Source Applications Foundation, which also is based on web dev. There's, of course, Apple iCar. There's another one which is called emclient and Outlook.
43:02
Actually, there's even an open source project called Open Connector, which implements a caldiff protocol, but it's not very fast. So if you are a developer which is into Windows development, they need a lot of help, really. So my section about actually writing such a connector.
43:24
As I said, it's not that, or shouldn't be that hard, because all the open source clients already implement the hard stuff, which is parsing and processing iCalendar and vCards. This is all done. All of the clients can do that. So what we need to add is basically a simple cache,
43:42
which keeps items retrieved by the server together with the ETag and the URL. So it's pretty easy. And well, as I said, if you want to start such a connector, please just do the group dev part working first,
44:00
because you shouldn't really look into caldiff extensions until the group dev stuff works. It's very simple, and if that works, you can start adding caldiff features with appropriate fallbacks to improve performance or provide additional features. But even if you just have group dev, it's quite good already. It can be used in a lot of sharing scenarios.
44:24
There are also quite a few libraries for doing caldiff. For example, caldiff for J and for Java. It's a Java library to do caldiff, caldiff client library for Python, open group as a library for caldiff stuff. V object is also a Python library.
44:42
The mulberry client also has a lot of caldiff functionality packaged in various languages as well. So, but still, I would say you don't need to use that, because the XML you need to parse is just the response from the prop-find query. It's just one XML format you need to parse,
45:03
and it would be completely overblown to use a separate client library for that. It doesn't make any sense. So you should just use your favorite HTTP library to retrieve the items from the server, parse, write one XML parser which parses that prop-find,
45:20
and that's it. Debugging tools. Well, if you're developing something, it's nice to have some stuff that you can use to actually try the thing, and I'll check where I can show you two. One is curl, and probably many people of you know that client.
45:41
It's just a command line client to retrieve HTTP servers using get or any other option. Need to check. It's a bit, does it work? Yeah, it's a bit small, the screen, but actually I've written myself a small shell script,
46:01
and the essential stuff is basically the bottom. So stuff at the top is just for collecting the password and stuff like that, and the bottom actually issues a prop-find, and the properties which are requested are in the prop-find XML file. So this actually contains a standardized prop-find
46:23
of group-dev, and it looks like that. So it's just the core set of properties which are necessary to implement the client. It actually contains some cal-dev and car-dev properties, so if the server actually supports those, okay,
46:43
supports those cal-dev protocols, or more of the cal-dev protocol, it can actually respond with data. A plain group-dev server would just not return anything. And for example, we can try that against some server. Actually, how did it come up?
47:06
Anyways, that's the iPhone.
47:21
Let me check, misprinted, yeah. So it's very convenient to see what the server actually responds with. So that's actually the Google calendar
47:41
which is requested using group-dev. As you can see, it probably responds to that with a prop-find response. That's the one you need to be able to pass. For example, the root URL, the Google Mail thing, is a root collection, and it contains additional stuff below. If there are any features it doesn't know,
48:02
it puts them in such a 404 section. For example, this collection doesn't have a display name or a specific content type, so it's quite nice. So that's a CURL, but it's quite easy to use to check what the server returns and what you need to pass, it's quite convenient. The other tool is Cadeva.
48:23
Cadeva is a command line client for web-dev. Let me see what I have. Okay, let's try the better work server, for example. So it's an interactive client. I can log in, and I can just go through a file system.
48:46
I can explore the server, and it's basically the functionality I would like to have in group your clients as well. For example, here's a calendar of the user, and there are the ICS files. I can just select one and make a cat,
49:03
and you see the icon in there. So you can use any web-dev client to browse such a server. That's pretty nice, and I can show you other servers. It's pretty easy. Let me check. For example, Scalable Ogo. I can just log into that.
49:23
So it actually has address box. For example, you can go to contacts, and those are all my address box, for example. Anyway, that's just regular vCard files. Oops.
49:41
Didn't copy. So it's just a vCard contained inside. So it's very useful for debugging. So, well, I'm actually almost done. Well, call for help. As I said, I would really like
50:01
to get the open-source client developers to support more of that, because I find it just ridiculous that they have very good exchange connectors, but no connector for group-dev or car-dev, because it's so easy for them. They already have icon and vCard, and they just need to implement. They even have the HTTP libraries for doing that.
50:21
They just need to implement the proper requests. Well, I've printed some features for Open Connector, which is the open-source Outlook integration. They need a lot of help. It's just one guy which is working on that. Well, so if you have any questions, you can write me email,
50:40
or the group-dev list is a good one to ask questions. There are calif and car-dev lists, and of course, you can go to the website. So, questions.
51:17
Scheduling isn't part of a group-dev. That would be car-dev scheduling,
51:21
but it's usually done using IMAP anyways, so it's scheduling based on email. But groups are basically just regular folders. The server can choose anything. It can choose to provide any hierarchy likes, and most servers I know also represents groups and the group calendars as subfolders,
51:42
and collision is perfectly detected. This is what HTTP eTecs are about, which allow optimistic locking, so there's no chance that writes collide. That's impossible. No, the server does that. It's standard HTTP.
52:01
That's done on the HTTP server. Yeah, with the client? Yeah, of course the client needs to handle collisions. That's true. But the server actually checks whether there could be a collision. No, it has something like an eTec,
52:21
which I explained before. I mean, time is a bit short to re-explain that, but it's perfectly working. There are no concurrency issues in that.
52:47
There are also test suites for car-dev. I know that. I never use them, but there's a test suite also at the Apple site, I think, which is in Putin and Python. So I don't remember the name, but you can check on the car-dev website.
53:01
It has a lot of implementations, and even the test suite, a link to that. So, sorry? Well, links to implementations. So, sorry, I can't follow you anymore.
53:28
Yeah, I thought you were asking for a test suite or something like that. Yeah, and there is a test suite, yeah? But not all servers implement everything in a test suite. So most servers just implement
53:40
what is required for iCar. Okay, yeah, thank you. Well, any more questions?
54:02
No? Okay.