Forum OpenACS Development: Re: Tcl Web Services Toolkit: TWiST

Collapse
Posted by Malte Sussdorff on
Hi Tom, yes, the idea is to provide an OpenACS package that uses ns_log, uses ad_proc (with procedure documentation). I am fine not releasing what I have done, but to be honest, in integration with OpenACS so far I had a decent amount of trouble just installing your code and getting it to work as it tries to be totally independent, which makes it more difficult to integrate.

Here are some of the issues:

* Namespace conflicts
* Reliance on a multi server setup
* Incorrect loading of wsdl-procedures
* Server errors due to "log" not being a recognized command

4) Yes, I see they are there, but you mentioned an example using dateTime, which seems to be missing.

Good to know that you are working on that though, if you do, then we should hopefully have a less burdensome installation process. And then we could have a wrapper package for OpenACS which provides documented procedures for the main functions used. This could then call "package require twist" and hopefully all is working. Because, if you provide this as an indepent API, then having package require working would be a major hit :-).

Again let me emphasise that I have no intention of taking over your code. I just wanted to get the current version and stuff it into an OpenACS package which is easy to use within OpenACS as we do it a lot of times e.g. with XinHA, AJAX and other tools that we find useful. But I do respect your wish not having it there, though then I would ask you to make the installation easier, which includes not touching the config.tcl file but be able to use "package require". Then I would also install it under /usr/local/aolserver/lib and not the TCL root of AOLserver (as it does not really belong there, in an OpenACS context).

Collapse
Posted by Malte Sussdorff on
One more thing:

To use it I manually have to link the WWW directory. This is not possible with an OpenACS package as you cannot know where the TWIST is installed in the first place. Why not break your package up into something that you unzip in the root directory of the server and which splits into the /tcl directory just as now, but also unzips relative links into the www directory, so at least you can access the files. Something like /www/twsdl/wsdl (as an example).

And for the documentation, at the moment I always have to manually go into the tcl directory to find the procedure. This is why I would love to exchange all occurances of "proc ::" with "ad_proc ::", so at least the procedure is avialable for browsing in the ACS API and I do not have to go back to the shell, go to the directory, open the file,search for the procedure, look what it does and what variables it expects and what variables it returns. This makes development really burdensome :-). This could be quickly fixed by you however. Just have a wrapper in init.tcl like:

if [lsearch [info procs ad_proc] ad_proc] <0} {
# insert the pass through definition for proc here
}

and then replace all instance of proc with ad_proc.

Collapse
Posted by Tom Jackson on
Malte said:

And for the documentation, at the moment I always have to manually go into the tcl directory to find the procedure. This is why I would love to exchange all occurances of "proc ::" with "ad_proc ::", so at least the procedure is avialable for browsing in the ACS API and I do not have to go back to the shell, go to the directory, open the file,search for the procedure, look what it does and what variables it expects and what variables it returns. This makes development really burdensome :-). This could be quickly fixed by you however. Just have a wrapper in init.tcl like:

You will not get very far with tWSDL or TWiST if you rely on the _static_ definition of ad_proc. You should use the inspect package which is part of tWSDL. You mount inspect anywhere you wish, by creating a symlink. I don't expect everyone to agree with me, but inspect gives you the current state of namespace variables and procedures, not what you think they are, or were at one point in time. Since most of the code in TWiST is autogenerated, you have to use something like this.

I know that as of right now, <ws>type and <ws>element are not documented, they are still in development and subject to minor changes. This does not mean that I need to rush out and use ad_proc, which would help nobody. I'm not really sure why anyone would recommend this. Did someone really do such a thing with tDOM, or with tcllib? How about Tcl itself? The world does not revolve around the OpenACS API, and complaints of this sort don't help anyone or solve any real problem. In fact, if I followed your instructions, the package would immediately only work for full installations of OpenACS. But, my goal is to abstract out even the dependencies on AOLserver, which will take very few hours as it only involves _one_ procedure in all of tWSDL! In the same way, I'm sure we can come up with a very thin layer to integrate TWiST with OpenACS, but not by hacking away on code which works.

Please keep in mind that TWiST is a _user_ API, tWSDL is a developer API. Unless you are very comfortable with how both work, it is way premature to start 'fixing' any code.

Collapse
Posted by Malte Sussdorff on
Contrary to perception, I looked at the inspect code before working on anything and have to say, I do not share your believes. But that is fine. I would only suggest to keep the proc definition and the arg_parser close to each other, as http://e4.cognovis.biz/twsdl/inspect/ns.tcl?ns=::pm::task is already hard to read but with both of them seperated it is even harder (again, only in my opinion and I do not have to rely on it).

My suggestion for ad_proc also and solemnly was referring to the procedures which we are actually using to create the webservices, not the auto generated code. Obviously that would be a little bit harder to achieve. Though I still think having support for < wsdl:documentation > would come in handy (but maybe it already does this and I just did not find in the documentation where). The way I would probably find ist useful:

< ws >type pattern datetime::year $yearAnchored xsd:integer documentation:"Year of the datetime"

Or use the way your hated (sorry :-) ) ad_proc does it for procedures

< ws >proc ::datetime::DayNameFromNumber {
{DayNumber:datetime::dayNumber}
} {
Returns the day of the week for a given number
} {
return .....
} returns {DayName:datetime::dayName}

Please be not offended by this suggestion. If you don't like it throw it away. I would be pleased to see your suggestions for creation and integration of < wsdl:documentation > tags, especially using the < ws > procedure.

Collapse
Posted by Tom Jackson on
Malte,

Have you read the installation instructions? This installs just like an AOLserver module, because it is an AOLserver module. I think what is confusing you is that I have used some OpenACS conventions in file naming (pkg-procs.tcl, pkg-init.tcl, etc.) These should be ignored by the user.

But really, you are asking design/development questions and criticisms prior to installation. Maybe you will find the functionality useless, but to be thinking about improving it for your own use at this point will be a big waste of your time and mine, and will give the impression that there is some issue which doesn't exist. The code is working, and you can test it for yourself at:

http://junom.com/ws/

If you are thinking about changing the API and incorporating it into OpenACS, please don't do that. At the very least it is somewhat rude to take over this role. But in fact, I have a stake in seeing that any OpenACS package works as expected, and continues to work into the future.

Otherwise please ask a specific question about installation, and explain _exactly_ what you are doing, and what instructions you are following.

Collapse
Posted by Malte Sussdorff on
I read the installation instructions and I managed to get the code to work 24 hours ago. In both variations, as per installation instructions and as an OpenACS package. Not sure how you come to the conclusion that I did not get it to work after my detailed questions. Well, whatever.

As mentioned before, I have no intention of taking over your code. I want to use it and make it easy to use in the environment I work with, which happens to be OpenACS. If you find the fact that I did this rude, please accept my apologies, as I have no intention of doing anything that might offend you (though, judging from the tone in your replies you are offended, for which I am sorry and just hope you will be able to accept my sincerest apologies).