[DGD]EPP 2.0

[Jason Cone]

----- Original Message -----
From: "Ludger Merkens" <balduin at uni-paderborn.de>


> [...]
> development) and where performance matters. A bridge to call c-functions
> from lpc would help alot. Writing kfuns for this purpose is possible, but
> I don't like to populate the driver with lots of functions because I think
> that would be bad design.

I would have to agree here.  I, too, would like to see this as it negates
having to distribute custom driver sources for use with specific libs (if
made publically available).

> I wouldn't place xml support into the
> auto-object, would I? Any ideas? What can be done about this problem?

As to the specific XML scenario, it's my belief that an XML interface is
best implemented as a DOM rather than a procedural API.  I've worked with
both COM-based DOMs and C (and Perl) APIs to access XML documents and have
found that DOMs make life much easier when working with such well-defined
documents as XML.  Given that, it would be a great idea to use the existing
object-oriented design of LPC and the parse_string() kfun to implement a
simple DOM for XML.  I've even considered overloading the save_object() and
restore_object() kfuns to allow for extended persistence in XML.  Alas, the
todo list keeps me from seriously considering it. ;)

Anyway, that's my 2 cents.

Jason



List config page:  http://list.imaginary.com/mailman/listinfo/dgd