Re: Workflow engine / GroupDAV

On Jan 7, 2005, at 15:27, Adam Tauno Williams wrote:
>> This sounds like usability might be awkward.
> I wouldn't describe it as elegant.  There are things like WDSL or UDDI
> that theoretically would make it more elegant, but nothing supports
> these things.  But it works and beats swapping around delimited or 
> fixed
> record length files (ack!).

Ups, I somehow assumed that WSDL is broadly supported in the UI tools 
to select the SOAP message in question. Notably WSDL also allows 
specification with REST semantics, which I personally would like much 
more.

But anyway, we should stop the discussion here ;-)


The GroupDAV issues should be directed to the GroupDAV list:
   [email protected]

>> The events itself are supposed to be contained in iCalendar and vCard
>> documents which are retrieved using GET and stored using PUT.
>
> Right, I can GET & PUT, these work as normal HTTP operations.

Yes.

> I don't think the GroupDAV document makes clear the format of the
> 'object'; OGo contains a great deal more information than is in a
> standard vCard.  And the pitance of information in a standard vCard,
> honestly, isn't terribly interesting.

GroupDAV isn't strictly about OGo. A lot of care has been (and will be) 
taken that it actually works with other servers and clients. Therefore 
we need to limit ourselves to some useful subset.
What iCal provides is exactly what most clients provide, even more 
exactly, Evolution, Kontact and Mozilla Calendar *all* do 
iCalendar/vCard, nothing more and nothing less.

So to be useful for the GroupDAV effort, a .NET GroupDAV implementation 
needs to conform strictly to the draft and may not try to use advanced 
OGo functions.

Having said that, we need some approach on how to work with advanced, 
non-groupdav data. This can be done using XML-RPC or other WebDAV 
support in ZideStore.
Of course we can also transport various additional infos in vCard/iCal 
x-ogo- properties. But as mentioned a GroupDAV client must not rely on 
such information.

> I also don't see (perhaps I'm missing it) how to query for items in a
> folder;   such as 'give me all contacts with a first name of steve'.
> Obviously this is possible, since the Noodle plugin does it, so I
> probably need to reverse engineer that.

Currently you are supposed to search on the client side. GroupDAV 
contains a lot of work on how to ensure a consistent client cache. I 
think the advantages/disadvantages should be pretty obvious.
We may specify additional DASL queries to query certain things, but I'm 
somewhat relunctant to add such as it will require much more 
functionality in the server, thereby lowering GroupDAV acceptance and 
interoperability.

API wise, a .NET GroupDAV client library should have two layers, one 
which implements the raw queries and one which implements the cache and 
operations on top of it. Of course it would be perfect if the cache 
would be pluggable (maybe implemented using ADO.NET?). Eg I can imagine 
a good performing cache being build on top of SQLite.

>>>> Are  there any iCalendar parsing libraries for Mono?
>>> I've looked, no luck so far.
>> So this is required. But parsing basic iCalendar/vCard isn't too
>> difficult either. It would be a requirement for GroupDAV though.
> I've enquired of a Dashboard/Beagle developer here in town; if there is
> one he'd know about it.

Thanks.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss