[XML-SIG] DOM API

[Greg Stein]

Lars Marius Garshol wrote:
>...
> * Greg Stein
> |
> | No particular reason, although it will be somewhat slower if based
> | on SAX.
> 
> It will, so maybe we should consider making two builders?

I have no motivation to do so :-), but will certainly accept the changes
from somebody who is.

> | I see in drv_pyexpat.py that the startElement handler does a good
> | bit of work before getting to the "real" start handler. It would be
> | nice to skip that :-) (honestly, though, I don't know what kind of
> | overhead it creates).
> 
> If you have a lot of attributes I guess it will be slow, but I think
> applications using your qp_xml will essentially have to redo that work
> (and quite possibly in a less efficient manner), since they can't just
> do a simple lookup to get the attribute values.
> 
> So your qp_xml would be nicer if it had a hash of attributes instead
> of a list, and applications based on it would very likely be faster.

Yes, I thought of this one, but looking at the code, I see that I
haven't actually done that yet. heh. I'm out for about two weeks, but
will change this when I return.

I intend to do { (URI, name) : value }.

> Also, I think it might make sense to modify pyexpat to create a hash
> in the PyAPI wrapping instead of a list as it does now. That would
> most likely be both the fastest and the nicest solution.

Yup. Should ask Jack about his intentions here. Keep it close to Expat,
or provide a little more Python-ish version. There is also the
backwards-compat issue :-)

> | It might be nice to switch it to SAX and bench the pure pyexpat
> | version against the SAX version.
> 
> Feel free. I don't have the time, I'm afraid.

Not me. As I said... I'm not motivated to do so :-).

I believe that multi-parser support is handled by DOM. If you want quick
and light-weight, then use qp_xml and pyexpat.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/