Re: [evolution-patches] Support for XML in the save-calendar plugin

[Not Zed <notzed ximian com>]

On Tue, 2004-12-14 at 00:13 +0100, Philip Van Hoof wrote:
> On Mon, 2004-12-13 at 17:50 -0500, Joe Shaw wrote:
> > On Mon, 2004-12-13 at 23:18 +0100, Philip Van Hoof wrote:
> > > Second I implemented a simple implementation for the XML-format in
> > > "xml-format.c". Currently the format is like this:
> > 
> > You might be interested in the ical RDF work here:
> > 
> >         http://www.w3.org/2002/12/cal/
> >         
> > It's similar to the standard RFC 2445 syntax and yours here so I don't
> > think it'd be significantly more work, and would probably be preferable
> > to creating a new syntax.
>
> Indeed. It's not hard to support this RDF-format using the xml-format.c
> implementation I've created.
Would it be better not to add another format though?  I think it would be unwise to add more subtle variations particularly if an existing standard will cover it.
> Perhaps I will convert this to rdf someday myself. Else I kindly invite
> anyone interested to do this. Please inform me about it first, to make
> sure we are not duplicating work here.
>
> I will probably implement it in rdf-format.c (and I will probably just
> remove xml-format.c as with this rdf-format it's no longer really
> interesting).
>
> But first (and before I am going to put time in converting it to use
> this RDF-format) I'd like to know whether or not the whole idea of
> "exporting-to-many-formats" -functionality for this
> "save-calendar"-plugin is a good idea and whether or not the current
> state of what I submitted is usable: Perhaps there's plans to add
> support for this RDF-format to libecal? In which case it doesn't sound
> like a good idea to again implement it in a rdf-format.c just for the
> "save-calendar"-plugin.
I'm not a calendar developer, but i wouldn't think it would make sense to support an interchange format internally.  They serve very different purposes.  We have 'importers' that should import whatever this thing exports though, but the current importer framework is messy.

I'd also highly recommend not creating your own xml format - if one exists that will serve the purpose.  I don't know, for example, what kolab uses for its xml format, and if it is just another representaiton of icalendar itself.

(anyway, just some hints/suggestions, not a demand).

 Z