[OGo-Evolution] Re: Evo 2.0

[Erik Romijn]

Hi Helge,

On Tue, 2004-10-19 at 15:52, Helge Hess wrote:
> > The current way tasks are implemented is: fetch the names from the
> > PROPFIND and do a GET on each task item.
> 
> The Connector accesses Exchange that way? (its not an OGo issue, 
> right?) Maybe Dan can explain why no BPROPFIND is used for tasks.
> 
No. The connector does a BPROPFIND, but that does not seem to be
supported by ZideStore. I may have overlooked something there though.

> What does the GET return? I suppose an iCal VTODO wrapped in a MIME 
> message?
If I remember correctly it does. I can't check it right now.
The format the connector expects is XML, so ex2ogo builds up the XML
data out of the VTODO's.

> > This is done because we could
> > not find a way to make zidestore return all the needed data for all the
> > tasks in a single request.
> I could probably create a method which returns all tasks in a single 
> call. What format would you prefer?
An XML format like the connector expects would be the most convenient,
as that would make ZideStore and the connector compatible in that part
without ex2ogo being needed to mangle data.
> 
> > Ofcourse this is very ugly and very slow.
> > The slowness can be 'prevented' with a caching system.
> Yes, the caching system is a good idea in any way, but as mentioned it 
> really belongs into the Connector ;-)
I agree on that. But this product is also something that our company
needs as soon as possible - if caching with zidestore and the connector
will take some time before it is implemented it would be more
interesting for us to implement something in ex2ogo for it too.

We would have to keep in mind that ex2ogo is more meant like a proof of
concept, which should become useless when the connector and zidestore
achieve compatibility with each other.