Re: Web development

[MJ Ray]

Sergey:
> > Yes, I've already downloaded the fastcgi interface, but I don't have
> > time to use it for my next deployment
> You shoud think carefully about it. All the fastcgi adds to your
> cgi application is "accept-loop"
>  ...some one time initialisation...
>  (while (fcgi:accept)
>    ...ordinal cgi...)
> It cost nothing, but have many benefits (you can easy share database
> conections for ex.)

It does have a slight cost, as the application would need to be restructured
a little to take advantage of these features and make sure that it did
everything else "properly" (I believe it does, but there's always something
hiding in there).  If rewritten to obtain optimal efficiency, by putting all
similar tasks in one process and using the path to select between them, then
you're not that far away from writing a webserver extension...

> >and I'm a bit limited by the "non-free" status of fastcgi.
> Really?

Indeed.  Some clients have agreed to the use of all DFSG-compliant licences,
but fastcgi is another unapproved licence for their legal people to check.

> > So, maybe someone on this list knows if there is a way to store
> > continuations?
> It's not main problem. You can keep continuation in memory.

This was what I was thinking.

> You can (best way) use XML. O! It's realy the best way

Surely there's nothing to be gained by converting to XML instead of
S-expressions?

>  But my problems are others:
>  i.Guile
>  1)I want to return to each http-query  continuation the same user
>  has been working before.

Why is this a problem?

>  2)User can "start transaction" during wich hi is modifing some
>  "transactional objects". In the moment he (or system) may decide to
>  "rollback" all chandes. But only for "transactional" objects no more.

Now I can see why this could be tricky, but surely using a private database
connection from a pool for that continutation would solve it?  The
continuation "housekeeper" would need to tidy up the database connection,
roll back the transaction and return the connection to the pool if it had to
reap the continuation.

But you say:

>    I've solved second task by inventing my goops-db system which
>    implement (define-transact-class) macro and metaclass which created
>    classes with "transactional" slots. But where (and how) should old
>    values of slots be saved? Especially arrays, lists and so on...

although I probably don't understand this yet.  ;-)

>   ii.HTTP
>   1)which user is the "same"? I've made http query... opened another
>   window and made second. Am i "same" user or not?

Usually, yes.  If you open another browser, then no.  Don't ask me why...
it's probably because "that's the way cookies work, so that's the convention
on the web".

>   iii.Apache.
>   Well. I defined policy, made user identity by cookies... But next http
>   query is handled _another_ httpd or fcgi process. Damn it!

Yes, this is why I think putting an http server in scheme is the way to
work.  While you have multiple httpds talking to multiple guiles, you can't
win.  Making multiple httpds talk to a single guile would work, but no
system offers it at present, does it?

> > in this line, as I've not got a clue on that part of the problem. 
> > Otherwise, the stand-alone server rather than the fastcgi is going to have
> > to be the way forwards.
> I think so... I've looked for for OpenSource multithreaded http server,
> knowing about russian encodings, having FastCGI and working on AIX.
> Failed.

Why is multithreading important?  Can you comment on the quality of serveez
or the slib http functions?  I've only taken cursory glances at each so far,
but intend to investigate further later.  Which of your criteria do they
fail, apart from the FastCGI bit?  For the reasons given above, avoiding
FastCGI would be fine by me.

-- 
MJR