> > I can't say that I've followed what this is about.. but if
> > it's something like wether "e" should have a good xml parser/api
> > vs. everyone who needs something like that having to write their
> > own... then I'd say it may be time for "e" to stop 'poo-poo-ing'
> > xml (mostly an excuse to avoid dealing with it) and consider
> > developing some solid support for it - for those that may wish
> > to NOT write their own when they need to use xml.
> > Like it or not, xml is here and not going away any time soon,
> > its use is almost universal - especially across the web, but also
> > locally as well.
> >
> > PS.
> > Wasn't there "exml" supposedly to deal with this? Or is that
> > another lib that has serious flaws or limitations?
> >
>
> Why write our own when libxml2 works quite well? Seems like needless
> NIH to me.
I agree. The only thing would be that one may want to have a
wrapper lib(s) that expose a certain api which might be more convenient
or easier or better fit to whatnot, etc.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
