[OGo-Evolution] working mangling daemon allowing basic OGo-Evolution

[Erik Romijn]

On Thu, 2004-10-21 at 11:49 +0200, Helge Hess wrote:
> On Oct 21, 2004, at 10:52, Erik Romijn wrote:
> > With a PROPPATCH ZideStore returns a HTTP501 (method not implemented). 
> > I thought that meant that the request was not supported.
> 
> Yes, I suppose this would be correct HTTP ;-)
> 
> ZideStore currently returns 501 whenever it encounters a requests which 
> it basically understands but can't handle. If there is a better 
> response code for this case, let me know.

Maybe a 405 would be appropriate.

>From HTTP RFC:
---snip---
405 Method Not Allowed
The method specified in the Request-Line is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow header
containing a list of valid methods for the requested resource.
---snap---


> > An addition to the PUT's on calendar items: Evo returns an error after
> > PUTting the item although it is added correctly. Probably ZideStore's
> > response would have to be modified to make Evo believe it was 
> > succesful.
> 
> What does it return at the moment? If its 200 (Ok), one might try 201 
> (Created).

Changing it to a 201 works. Evo now also displays the item after it has
been added, without evo thinking it was successful a restart was
required to display it.
Implemented in ex2ogo-0.1.1 (although it's not much special):
http://oracle.toltech.nl/~erik/ex2ogo-0.1.1.pl
Shouldn't be too hard to implement in ZideStore I guess.

On the required restart of evo: as far as I understood from the
connector people the connector uses SUBSCRIBE to make the server tell
the connector when data is updated. In it's current form it doesn't seem
to work, haven't looked into it very far.

I think I'll start taking a look at compatibility between Evo's alarm
and OGo's reminder. It guess it should be possible to convert between
the two.

Greetings,
Erik Romijn