Forum OpenACS Development: Re: Remoting (Formerly: The future of OpenACS)

I'd wish you wouldn't have played this card, as most of the issues listed and mentioned can easily be discussed without referring to YOUR and MY piece of work. If I remember correctly, the idea of the thread (as it was started by Malte) was to collect ideas and requirements for remoting solutions for OpenACS, and not whether YOURS or MINE are better suited.

Ummm, you started this thread.

I have never looked at your software, don't know where to get it or how it works. I use my software as an example for several reasons, but I'm not promoting it. Anyway, the main reason for discussing software which actually exists is because it is obvious how things are done, while talking about stuff which could work or might be better is a waste of time. Until something is boiled down to code, everything sounds possible, that is the nature of programming languages: anything can be done, in any language.

Another reason to talk about existing code is that code has behavior. If you want to discuss a future requirement, it is good to know how other people have actually solved the problem, what is involved. That is why I was looking for examples from other major players in 'remoting'. I talked about, and provided links to the ones I know about. Personally I'm not interested in re-inventing the wheel. When someone tries to code to a standard, they are giving up that part of the process. I have said I tried to follow the recommendations in WS-I Basic Profile. If you don't wish to follow a standard, it becomes very difficult to compare it to anything else. It does make it easier for you to claim that your software works and does what you want.

I don't quite understand why you are so interested in examples from compiler language environments. Scripting languages are much more powerful in this respect!

I listed the examples I could find, I asked for better examples. I'm still waiting.

This I don't quite understand, provided that I understood your guiding scenario. You want to have a language-bound code block turned into a service + service description, but you want simple types (xs based types) not defined in the very language the code block was written? this is conflicting and contradictory to your scenario.

Ahhh! Yes! This is exactly the advantage of Tcl over most other languages in this area. First consider the following: Tcl is best as a glue language. In OpenACS it is a glue language. OpenACS doesn't store information as a Tcl structure, it takes in some string and passes on a string to another application. Usually stuff goes into a database, which does have type requirements. Most procedures don't care what they take in, so you claim that the typing of this input or output doesn't make sense. Actually what doesn't make sense is caring about constructing types in Tcl just to pass them on to another application. But if you can test the type information, you can pass back information to the client in a useful form. Once the procedure executes, you pass from client error to server error, which is much less useful. This is why we have filters in ad_page_contract, not because the Tcl layer necessarily cares, but it is easier to return error information to the client.

Besides simple typing and derivation, more important is structural typing. Structural typing is very important. Every langauge is slightly different and the point of WSDL using XML-Schema to describe how to construct types is that it is theoretically easy to build software which could validate a type (simple or complex). Does XML-Schema suck: big time. But one of the biggest sucking parts is that it tries too hard to accommodate optimized validation routines and fuzzy types.

Anyway, I'm not soo sure what is contradictory: WSDL defines an interface, at some point there has to be code which translates from an XML/SOAP document to Tcl. This is required.

The question is rather what is the realm of validation:

The question is what helps the client, targeted error messages which relate to the data input, or a stacktrace from the server? Of course, validation also protects the server from attack. I'm not too impressed with MS releasing code which is all too happy to stick any data into any variable. My general rule is to validate as soon as possible, why wait? Oh, and it is a requirement with SOAP/WS-I that client errors should lead to no change in state on the server. The best way to ensure that is by validation before execution.

This is a matter of framework design and, again, the employment of design patterns: Provide signature adapters with the adapters being exposed as service.

Yes again! <ws>proc is an adapter! Actually it is a description of an adapter. The adapter is written by tWSDL based upon the input to <ws>proc. Very complex adapters have to be written by hand, although I haven't thought of a realistic example which would require this.

This is a basic requirement and the solution in most frameworks is referred to as "deployment descriptors". They come in various flavours, in AXIS they are XML-based descriptors, in ASP.NET they come as annotation tags, ...

Yes, this is how they do it. All the examples I have found are for very simple services. I know they can do more, obviously, but how easy it is? More importantly, how do you learn how to do it, where are the complex examples? I'm interested in example code. Another thing that is still missing is using annotations _and_ using complexTypes or derived types and not having to edit a bunch of files.

I would like to promote something, two things: efficiency and simplicity. If you can boil out the information content which distinguishes one remoting service from another, you can write code which uses this tiny amount of information to write the actual code. One example of what information is required for a service is a WSDL file. It isn't the only example, but it is a good one. It doesn't contain all the information needed since the adapter information is missing. A more complex solution will require more information, more software to handle the complexity, etc.

Anyway, I'm not interested in your remoting whatever. TWiST does what it does and doesn't need to be integrated with some ambiguous uber-code. Why not just release the code you have right now?