Forum OpenACS Development: Upgrading ns_xml

Collapse
Posted by John Mileham on
Hi all,

I've been doing quite a bit of work with ns_xml of late and have run against some serious limitations in the API. Because it appears that this module is fairly ownerless, I thought I would take a stab at releasing the changes that I make as a generalized ns_xml 2.0. I have posted documentation on my proposed changes at https://openacs.org/new-file-storage/download/nsxml-2.html? version_id=477. Please let me know what you think.

Collapse
Posted by Don Baccus on
I just skimmed it but my first impression is ... well, my first impression is that it's very nice to see a well-written design proposal, actually!  Looks good.

Currently OpenACS 4 makes very little use of ns_xml, in the core just to parse query files and to parse package .info files.  It's not used to generate .info files, nor is the XML doc tree retained after a .info file is parsed.

Obviously we're going to be making much heavier use of it in the future, especially in client packages.  So having someone pick this up, improve it and perhaps continue to maintain it for some time, at least ... yeah, it's great.

Collapse
Posted by Dave Bauer on
Is ns_xml the best XML option?

I am wondering because I am working on intergrating NSSoap[1] into OpenACS and it uses nsexpat and nstcldom, to provide XML services for AOLserver.

Of course if we abstract the xml parsing out well enough it might not matter which parser is used. I was just wondering if it would be best to only rely on one parser for an installation.

[1] http://nssoap.sf.net

Collapse
Posted by Ken Kennedy on
Well, I certainly like the idea of having the module supported. I have an extension to the bookmarks module using XML-RPC (to allow client prgs to retreive, update, and manipulate bookmarks) that I'm tweaking in my OpenACS 3.X system now. Once we're stable with 4.X, I'll be porting it over.

On another (though related) note, though...Dave, what's up with the NSSoap module? Holy smokes, that'd be cool. I see no files as SF yet...is there anything available? (I also have some potential patches to ns_xmlrpc I need to send your way, when I get organized...*grin*)

So, I guess I vote for any and all modules that support my XML-RPC stuff!

Collapse
Posted by Dave Bauer on
Regarding NSSoap, I have just checked out the CVS and started to work with it. So I don't know anything about performance or how it works yet. When it is done it will support XMLRPC and SOAP for the same methods.

I am going to setup an acs-service contract to allow packages to export procs via SOAP/XMLRPC and also call methods exported by an external server.

Collapse
Posted by Bjorn Thor Jonsson on
This might also be worth a look:

Using tDOM and tDOM XSLT
A high-performance Tcl-scripted XSLT engine
http://www-106.ibm.com/developerworks/xml/library/x-tdom.html

tDOM is a high-performance, C-coded, DOM-oriented XML processor. tDOM XSLT is an XSLT engine built with tDOM that has extremely good performance in simple tests. tDOM and tDOM XSLT are open-source projects already in mission-critical production for several organizations. This article explains what you need to know to enjoy their advantages.

Simple benchmarks show that tDOM is one of the best-performing XML processors currently available. Access through the Tcl "scripting" language makes for a particularly potent development environment -- fast in both development and execution. A "dual level" (or two-language) model of development combines the advantages of Tcl and XSLT for different aspects of XML manipulation.

...

Engineer Zoran Vasiljevic builds tDOM into AOLserver for very high performance DOM-based HTML generation.

Collapse
Posted by Dave Bauer on
One other option I am looking at is to build an XML service contract so that there is a generic API to OpenACS modules for XML and the details are handled by an package the maps whatever XML parser you choose to the service contracts.

The tricky part, of course, is designing the service contract so they are flexible enough and give the developer the options they need so they don't have to get to the XML processor underneath.

Collapse
Posted by John Mileham on
Just an update. I'm testing ns_xml 2.0 now, and will hopefully be able to release it as a beta in the next week or two.  As far as other options go, I haven't had the chance to play with them.  ns_xml was the closest thing to what I needed, was already embedded in the current version of OpenACS, and it was readily available.  ns_xml 2.0 provides all of the basic tree manipulation functionality that I imagine a web developer needing (with the possible exception of on-the-fly DTD validation and manipulation of XSL - at least as anything of more semantic significance than the XML that it, by definition, is).  Does anybody care to comment on the design?  It seems to me that if you want relatively fast XML with XSLT and relatively robust tree manipulation, and if, like me, you want (or in my case need) it nowish, this is worth a look.
So is anyone out there actually in possession of a working solution for sending/handling SOAP requests?
Collapse
Posted by Jerry Asher on
Henry, today I received this in my email, (perhaps someone was awaiting your post?)
Project: TclSOAP  (tclsoap)
Package: tclsoap
Date   : 2002-02-27 01:20

Project "TclSOAP" ('tclsoap') has released the new version of package 'tclsoap'.
You can download it from SourceForge by following this link:
http://sourceforge.net/project/showfiles.php?group_id=25970&release_id=77119
or browse Release Notes and ChangeLog by visiting this link:
http://sourceforge.net/project/shownotes.php?release_id=77119 
That package supposedly supports SOAP for AOLserver and you'll have add your own OACS wrapper.