Tcl Web Service with Authorization kills Tcl

On Mar 26, 2:33 pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Mar 26, 6:42 am, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> 

> I also have a pure Tcl replacement for the AOLserver API (server
> layer), at least enough to serve web services and tcl pages.

How does this Tcl replacement for the AOLserver API compare
with nstcl (http://sourceforge.net/projects/nstcl/) and nstclhttpd
(http://sourceforge.net/projects/nstclhttpd/)?

escargo

tom.rmadilo wrote:
> On Mar 26, 1:51 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote: 
>
> Right, so for instance the below proc uses ::Httpd_ReturnData:
>
> proc ::WS::Server::callOperation {service sock args} {...}
>
>
> My thought is that the callOperation would change so that it doesn't
> handle the sock, but probably the caller, or higher level wrapper, of
> this proc would do that.

That would be fine, the only thing that any of the routines use the socket
for is to pass it to ::Httpd_ReturnData.

The other option would be to have the caller pass in a dummy socket and have
a ::Httpd_ReturnData stub that stores the results which the caller then
accesses and does what it has to with.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

On Mar 27, 5:38 am, escargo <esca...@skypoint.com> wrote: 
>
> How does this Tcl replacement for the AOLserver API compare
> with nstcl (http://sourceforge.net/projects/nstcl/) and nstclhttpd
> (http://sourceforge.net/projects/nstclhttpd/)?

First, note that I said "at least enough to serve web services and tcl
pages". AOLserver does much more than that, but web services are
pretty thin on requirements compared to a generic web server.

Also note that I am not interested in replacing AOLserver, the
replacement layer allows me to use some other I/O model to handle web
services (including a unix pipeline). Since my tWSDL/TWiST application
is not deeply invested in the AOLserver API, it was relatively easy to
create a replacement layer. tWSDL/TWiST was developed for AOLserver,
but the same code and configuration files work with many different I/O
models.

I stopped investigating this problem further. I've more than 20 tclhttpd
server running on SunOS and Linux boxes with different operating system
versions. But there is only one box actually causing segmentation fault
problems. It's my athlon box using SuSE Linux 10.x used only for
software development.

schlenk schrieb: 
>
> This sounds really weird..., tdom should not use libtclexpat, (unless
> something changed in how AS builds their distro). tdom builds in expat
> lib statically, and libtclexpat does too.., (tclexpat should be from
> the tclxml package). There was some discussion about problems this
> might cause between Jeff Hobbs and Rolf Ade IIRC, but not sure about
> the details.
>
> Try getting libtclexpat out of the picture...
>
> Michael
>
>
>
>

In article <b2e0ac27-21e9-47e7-abdd-1a7df0d6b901@d4g2000prg.googlegroups.com
>,
schlenk  <schlenk@uni-oldenburg.de> wrote:
> 
>
>This sounds really weird..., tdom should not use libtclexpat, (unless
>something changed in how AS builds their distro). tdom builds in expat
>lib statically, and libtclexpat does too.., (tclexpat should be from
>the tclxml package). There was some discussion about problems this
>might cause between Jeff Hobbs and Rolf Ade IIRC, but not sure about
>the details.
>
>Try getting libtclexpat out of the picture...

Michael is definitely right. tdom (at least with an unhacked build
system) does not use libtclexpat, but links expat statically.

But yes, there seem to be some difficult to solve problems (even the
gurus hadn't an adivce, so far), if you do both [package require tdom]
and [package require tclxml].

rolf

tom.rmadilo schrieb:

> My opinion is that tclhttpd is a disaster

What about Tclhttpd is a disaster?
I find it very pleasant and enjoyable to develop web applications on it,
compared to AOLserver...

Eckhard

Both packages SOAP and WSDL are planned to be avaiable on my tclhttpd
servers. But using both of them seems to be not possible.

But is it a restriction to be bound to one of them?


The segmentation fault while executing some WSDL commands happened due
to SOAP using Tclexpat. A forgotten link to a source file using

package require SOAP::Domain 1.4
SOAP::export ...

loaded the package before package WSDL. I do not know why/how basic
authorization blew up the problem after all.


schlenk schrieb: 
>
> This sounds really weird..., tdom should not use libtclexpat, (unless
> something changed in how AS builds their distro). tdom builds in expat
> lib statically, and libtclexpat does too.., (tclexpat should be from
> the tclxml package). There was some discussion about problems this
> might cause between Jeff Hobbs and Rolf Ade IIRC, but not sure about
> the details.
>
> Try getting libtclexpat out of the picture...
>
> Michael
>
>
>
>

On Mar 29, 4:33 pm, EL <eckhardnos...@gmx.de> wrote:
> tom.rmadilo schrieb:
> 
>
> What about Tclhttpd is a disaster?
> I find it very pleasant and enjoyable to develop web applications on it,
> compared to AOLserver...

Well, you started another thread "why...."?

Application servers are very hard to write. If you don't write them
correctly, you get questions like yours.

Tclhttpd is first of all: slow. But unfortunately, you have to write
code which is tied to the server. I think that it is best to write
most code in a server independent environment, and then link it to the
I/O model. It is slightly easier to do this with AOLserver, but you
can't guarantee it in either case. But, since AOLserver doesn't use
the event loop, it is easier to write code without regard to I/O.

On Mar 31, 8:28 pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:

I must add that I too find it a pleasant environment to write web
applications.  Very easy too.



> Tclhttpd is first of all: slow. But unfortunately, you have to write
> code which is tied to the server. I think that it is best to write
> most code in a server independent environment, and then link it to the

In terms of speed, no user has complained yet.  Indeed, it seems to be
faster than some alternative technologies.


The code we write for web development is independent of the web model,
apart from the html generation parts.  As a matter of fact., a large
part of the code is reused in a desktop environment.

On Mar 27, 8:57 pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
> On Mar 27, 5:38 am, escargo <esca...@skypoint.com> wrote:
> 
> 
>
> First, note that I said "at least enough to serve web services and tcl
> pages". AOLserver does much more than that, but web services are
> pretty thin on requirements compared to a generic web server.
>
> Also note that I am not interested in replacing AOLserver, the
> replacement layer allows me to use some other I/O model to handle web
> services (including a unix pipeline). Since my tWSDL/TWiST application
> is not deeply invested in the AOLserver API, it was relatively easy to
> create a replacement layer. tWSDL/TWiST was developed for AOLserver,
> but the same code and configuration files work with many different I/O
> models.

OK. That means that you are minimizing what you are doing, and not
providing any comparison between what you provide and what the
other packages provide. Somebody else will have to do the comparison
then.

escargo