[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]DGEE/CSLIB Question about webservices lifetime

From: Gopal V
Subject: Re: [DotGNU]DGEE/CSLIB Question about webservices lifetime
Date: Fri, 1 Aug 2003 20:19:01 +0530
User-agent: Mutt/1.2.5i

If memory serves me right, James Michael DuPont wrote:
> Well the client can wait. But the server might have to ask the client a
> question , or the client might want to post mutiple sets of data and
> have them all land in the same processses.

That just can't be done with a middleware system without some explicit
means of ensuring state ...

> :( why not? 

Because HTTP just doesn't work that way .... try storing to a local
variable in CGI or PHP code ... Even if HTTP were to allow it , the
rest of DGEE is built on the basis of any VM process can handle a
class of requests ("class" meaning group or classification) .. This
allows for multiple VMs to be run simultaneously or even on different

> Each other request passes that token in. the webserver has the
> responability to keep the process alive, or freeze and thaw the process
> as needed.

Such session-id based systems are possible, but you still need 
some place to store the data that needs to be stored (like a Pgsql
server) and perform operations, update . Maybe we'll have a set of 
helper classes to do this ?

If you look at xmlrpc with phpgw , you'll notice that they pass
sessionid:kp3 as the user:password of HTTP communication ...

And also the term "webserver" doesn't even surface for DGEE VM instances.

> Rhys? Is is possible to just save the state of ilrun as a core file?

And reserve 8-10Mb per call ?... be practical , there's no need to 
save the entire thing , only a few things and that too from the 
application level , rather than the VM level.

If I had a bit more time on my hand, I'd have shown up with an
example of session based webservices.

The difference between insanity and genius is measured by success

reply via email to

[Prev in Thread] Current Thread [Next in Thread]