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

Collapse
Posted by Tom Jackson on
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.

Collapse
Posted by Stefan Sobernig on
Ummm, you started this thread.
Nope, if I remember correctly, it was Malte starting the thread on remoting, by collecting some rough scenarios. I continued by summarizing what had been discussed during the OpenACS Spring Conference, still focussing on a general road mapping. It was you going into design + implementation details (of TWiST/tWSDL) which I somehow found inappropriate in a Future-of-OpenACS thread and therefore forked the original. However, my idea was still a general road mapping. C'est tout.
I listed the examples I could find, I asked for better examples. I'm still waiting.
Mmmh, if you are looking for "better examples" to the AXIS/.NET/... examples posted by you, simple googling won't be enough. I had good experiences with browsing the code repositories (especially the test suites contained in there) and getting my hands dirty with re-implementing and extending test cases for my purposes. If this is no option for you, mailing to the developer lists may help (that's why I indicated an example thread from the mono-devel list previously). At least, either of these options is better than posting a request to this forum.
What can be done? Have the most experienced people with regards to webservices (Stefan and Tom) along with interested OCT members come up with a generic strategy how to support webservices in OpenACS.
Taking up Malte's original statement, I would like to call a spade a spade. Tom, would you be willing to contribute (a) to a phase of general + detailed requirements gathering/ road mapping and, subsequently, (b) realising implementation efforts, even though they go beyond the scope of TWiST/tWSDL and might even replace these two as self-contained solutions?
Collapse
Posted by Tom Jackson on
I really wish I could figure out what I did that was inappropriate. Discussing code? This isn't a tea party.

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?

Collapse
Posted by Stefan Sobernig on
Tom,
Anyway, I'm not interested in your remoting whatever.

I got this strong impression, indeed! However, you constantly become set on MY, YOURS, THEIRS etc. I was never referring to MY fetish necessarily being THE solution for OpenACS, I just wanted to know whether there is esprit for co-ordinated action.

TWiST does what it does and doesn't need to be integrated with some ambiguous uber-code.

At least in this respect, I got an honest answer. Thanks for making this clear to me.

Why not just release the code you have right now?
Why? The only thing that prevents me from doing so is the fact that I am currently on holidays and that I am not fully available to support (early) adopters. I will be back to office around the end of next week, so expect the release around that weekend.

I, therefore, close this enlightening tea party from my side ...