On Tue, May 27, 2008 at 11:52 AM, Ferran Basora <fcsonline@xxxxxxxxx> wrote: > > > > > On Tue, May 27, 2008 at 11:56 AM, Øyvind Kolås <pippin@xxxxxxxx> wrote: >> >> On Tue, May 27, 2008 at 9:09 AM, Ferran Basora <fcsonline@xxxxxxxxx> >> wrote: >> > Hello, >> > >> > I have been watching the code about reading and generation of XML in >> > GEGL. I >> > think it is obsolete and pour extensible. >> >> This code should not be extended much, if at all, it should perhaps be >> cleaned up, but that also pends on reaching agreement/consensus on the >> OpenRaster specification at freedesktop. Right now the current code >> serves the purpose and it is not meant to be extended much even when >> reshaped to be more inline with the OpenRaster plans. > > We may not have to extend the code but clean. This cleaning could just as well take place without adding a huge external dependency, after all serialization to an XML format as well as loading it is quite far outside the core functionality of GEGL and might be suited for frameworks, libraries or applications on top. > As you say we have to wait for a final specification of > OpenRaster format, but is propable that OpenRaster format > will be a structure in XML, as OpenDocument. > For this reason GEGL will need an interface to load OpenRaster format > from an XML. I do not see feasible to remove completely > all the XML functionality. It shold be possible to implement all of the XML funcitonality using the other API and thus make the XML handling be an external library, perhaps called gegl-openraster or similar, for such a library a dependency on an external XML handling framework makes more sense. For internal XML need for GEGL (meta operations for instance), GMarkup which is currently used is sufficient. Waiting for a final specification of OpenRaster doesn't make sense, we need to prototype things and check out how much of what has been created would be possible to push into OpenRaster, open raster is in part specified due to how the XML handling is done/being planned to potentially be done in GEGL. GEGL never has promised to handle OpenRaster in any way, and the API documentation warns that the current XML is a stopgap measure that might be radically changed. OpenRaster is probably too domain specific since it might be difficult to push for instance the more video editing and compositing like things people would want to do with GEGL (ref http://pippin.gimp.org/oxide/) which is a precursor/inspiration for OpenRaster, that extends the scope to animations and sequences of clips. Going down a route of making the OpenRaster/tree based XML less prominent in GEGL is probably sane since the pure internal representation of GEGL does not use trees. A more free form XML for describing the graph for use with the meta operation as well might replace all of the existing XML. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
