[XML-SIG] DOM API
Thu, 22 Apr 1999 00:35:32 -0600
> 4DOM has a quick API? Or are you saying that the Python-ish extensions
> would *be* the quick API? Does 4DOM still require the installation of an
No. We removed that restriction several versions ago. You can just use the
"make orbless" configuration to run without an ORB.
> Anyhow, the main thing I prefer about PyDOM is not performance but the
> fact that my customers don't have to install an ORB to use it.
Well, by that criteria, now you have a choice.
I have to second your summary to Fred. I'm not as hung up with performance.
We've used 4DOM for some heavy lifting (not to mention Mike's diversion
writing a graphics-heavy Web-based solitaire game in Fnorb: we need to find
him more to do). We tend to run into bottlenecks elsewhere before the DOM.
> * we could make an API that used Python-ish features without being
> incompatible with the DOM.
The only problem for 4DOM is those double-underscore methods. Maybe there's a
way to wrapper this that escapes me.
> * 4DOM could add the Python-ish features and PyDOM could fix any outright
> incompatibilities (e.g. attrs)
> * maybe we could add a few convenience functions to make life easier
> (e.g. getText, getChildElements)
I have no problem with this. We already add many such convenient methods to
our 4DOM Ext package: GetElementsByTagName, GetElementsById, Strip, etc.
These mostly use the DOM level 2 NodeIterator stuff, BTW.
> * programs that used some DOM features would be incompatible with PyDOM
> because it would have optimized some of them away.
As long as it's documented, I don't see this as a problem.
> * programs that used the Python-ish features would not work over an ORB.
> Actually, I don't buy that last point (maybe its a straw person). We can
> easily make a bridge that adds the Pythonish features to objects on the
> other side of an ORB (4DOM, Java, whatever). Of course when you are using
> 4DOM in the same process space you wouldn't use the bridge.
Yes, but some Pythonish features would be quite a bear to get by an IDL
compiler, and it's nice being able to (theoretically) just plug into any
Java/C++/etc. module across the ORB without first adding a trickly "Pythonic"
adapter. This adapter would also have to be re-written for each remote
> In summary, I think that unifying the APIs of these libraries is the right
> thing to do and will give real benefits.
Well, we're certainly interested, and I think that if we can sort out the
double-underscore thing, we're most of the way there.
FourThought LLC, IT Consultants
Software engineering, project management, Intranets and Extranets