Did you use the package manager to create the .apm?

I ask because there seems to be a little problem when uncompressing it via "/acs-admin/apm/package-load":


Accessing /tmp/SOAP-Gateway-0.1d.apm...

      The follow error occured during the uncompression process:

child process exited abnormally

This might break support for PG 7.2*, though, but I don't know for sure.

I also get:


'Request Error

can't read "diffdata": no such variable'


...when I follow the "Create new namespace" link.


The code says something about "debug"...

/Ola

This package seems to be configured only for supporting the server end of a soap connection, and I don't see how one goes about generating the client stubs needed for invoking a service?  Are there some utilities for generating the client stubs, or do I need to do this part manually?  I haven't looked through the whole package, so I may be missing it.

Does the IDL only support basic types like int, float, string, etc?  If so, how difficult would it be to extend the IDL to support more complex types?

Overall, the package looks to be very nicely done.

Which remind me ... I bet the work that was done to get 4.6 to install under PG 7.3 totally ignored the timestamp/timestamptz issues.  I bet none of the time manipulation code in acs-reference works unless the datamodel is modified to use timestamptz.

Someone's going to have to sit down and evaluate the impact of timestamp no longer carrying timezone information before we support PG 7.3.  We may be stuck dropping PG 7.2 support for 4.7.

For now, if you're interested in the soap-gateway package, I recommend using whatever techniques you now employ to generate your stubs. Most likely, I'll provide another parameter in the WSDL fetch that allows a developer to specify stub generation. I've done this for C++ in another project and I can certainly do it for this one as well. The first blast would target the OpenACS/ns_xml/tcl combo. Upon fetching the WSDL generated code, you'd park it somewhere in your OpenACS code base. I'll extend the SG's source library management pages to include stub management.

Out of curiosity, what flavor of complex types do you require? Basic arrays, structures, arbitrary ranges within multi-dimensional arrays....

Ah, and there's still the issue of attachments...  what are your thoughts on the DIME spec?

As far as complex types, I'm currently using arrays of structures (java beans), but I'm sure that having other complex types like multi-dimensional arrays and structures that contain nested structures would also be useful.

I haven't used attachments, other than to try a few attachment based demos, but I definitely think they would be worth having.

With regards to the use of tDom, using the xml abstraction procs in openacs would probably be the way to go for now, so you don't have to rewrite everything when openacs goes from ns_xml to tDom.

This seems to be the de facto location to place packages which haven't yet been blessed for inclusion in the official distribution.  Though it's not the best solution, it seems to be the current one and it does make it easier for users to locate "other" packages.

On a more general note, we need to think of a way to better organize user-contributed modules.  Any ideas?  (Maybe a question for a new thread.)

To do this, I'll make a contrib/packages subdirectory to the openacs-4 project.

We will gingerly start opening this up as we start thinking about criteria for inclusion of user-contributed packages (we want *some* level of quality assurance, don't we???)

Anyway ... the SOAP stuff's extremely important and as William's stuff gets tested, vetted, polished etc I can't imagine it won't go into our main CVS tree.  Assuming he wants it to, of course!

Hello William,

First, thanks a lot for contributing this package...

I downloaded this version, installed the APM and mounted the application on a folder called soap. When I try to access the service, I get this error:

06/May/2003:14:46:42][742.45288448][-sched:16-] Notice: Running scheduled proc sg_boot_libraries...
[06/May/2003:14:46:42][742.45288448][-sched:16-] Debug: NO FULLQUERY FOR dbqd.soap-gateway.tcl.soap-gateway-db-procs.sg_library_get_paths. --> using default SQL
[06/May/2003:14:46:42][742.45288448][-sched:16-] Notice: Querying '
                select path
                from sg_libraries;'
[06/May/2003:14:46:42][742.45288448][-sched:16-] Error: Ns_PgExec: result status: 7 message: ERROR:  Relation "sg_libraries" does not exist

[06/May/2003:14:46:42][742.45288448][-sched:16-] Error: dbinit: error(localhost::development,ERROR:  Relation "sg_libraries" does not exist
): '
                select path
                from sg_libraries;
        '
[06/May/2003:14:46:42][742.45288448][-sched:16-] Error: Database operation "select" failed (exception NSDB, "Query was not a statement returning rows.")

ERROR:  Relation "sg_libraries" does not exist

SQL: 
                select path
                from sg_libraries;

Database operation "select" failed (exception NSDB, "Query was not a statement returning rows.")

ERROR:  Relation "sg_libraries" does not exist

SQL: 
                select path
                from sg_libraries;

    while executing
"ns_pg_bind select nsdb0 {
                select path
                from sg_libraries;
        }"
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql"
    invoked from within

Thanks.

Thanks for the reply. Unfortunately I don't know why the "-create.sql" file wasn't run properly. I will look into that when I am back in the office (today, monday, is a holiday here in the Netherlands).

The good thing is that it runs perfectly after loading the datamodel. I haven't had time to look more in details into it but I think I will have to as we are having some talks of using SOAP to communicate between some databases and our OpenACS installation... I managed to debug some SOAP messages with XML-SPY so that worked nicely. Generated some simple messages as well with Java (Apache AXIS and JAXP as well).... so this shouldn't be too complicated :)

Thanks again.

- Bill