[XML-SIG] DOM API

[uche.ogbuji@fourthought.com]

> 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
> ORB?

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 
implementation.

> 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.

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org