Re: scm_* API extension? [was] scm_* API question

[rm@fabula.de]

On Mon, Aug 05, 2002 at 07:51:11PM +0200, Marius Vollmer wrote:
[...]
> > 
> > Yes, this is exactly the situation i just encountered. I know that
> > everyone and their grandmother tells me to write everything in the
> > scripting language but i just don't feel like rewriting Apache in guile --
> > besides: that might p**s of a lot of perl hackers ;-)
> 
> I think just makes sense to write as much of your system in the
> extension language as possible, once you have an extension language.

I'd fully agree with you if we where talking about an application
that has _one_ extension language ([X]emacs comes to mind). If most
of the code lives in extension space the whole system gets more felxible.
BUT, here we talk about Apache, where we have mod_{perl python lisp haskell
...} and a plehora of utility functions so mighty that they got factored
into their own library. If i where to write my own webserver i'd probaby
code the URL dispatch in scheme, but i think it would be a waste of time
not using Apaches existing functionality for that (and, i have to admit,
it's pretty impressive fast :) As a side effect, a can mix extensions written
in different languages (have my access controlled by a C-level LDAP module
and have my logging done in TCL ...

> If you'd rather write it in C..., well, I guess we have to just accept
> that.

Not a question of language preference. Maybe i got to much used to
"how mod_perl" does it, but then, it's not the worst way.

> >  - save execution/evaluation of script code. I need to ensure that i
> >    can reliably dissable certain things: a user script should not be
> >    allowed to call (exit 0) and bring down the whole webserver ;-)
> 
> However, you should be careful not to accidentally reimplement the
> OS's security features in your application.  The fewer code you have
> to trust the better.  I don't want to trust Java to keep its sandboxes
> clean.  I'd rather factor the application into a number of processes
> that run in a chroot jail with their own uid/gid and have the
> kernel/hardware watch them.  Untrusted external code would be run
> inside such a restricted process.

Hmm, i don't think these things exclude each other -- i'd say: use both.
Especially with webserver you need both. Apache, for example can be con-
figured to provide 'Virtual Servers'. Often on server process has to server
requests for many different domains (read: probably many different customers)
the one jailed process per security realm doesn't realy work.

> >  - An (opaque) representation of an 'interpreter'. One thing i found 
> >    rather elegant in TCL (perl to, if i recall correctly) was the
> >    possiblility to run several interpreters in parallel. Guile seems
> >    to completly lack this (i think i understand why, but i still miss
> >    it).
> 
> What is an 'interpreter'?  What do multiple instances of the
> interpreter have in common, what is specific to each instance?  I
> think that once you know what you want from multiple interpreters, you
> can implement them easily with the features we already have.  Or with
> fork.

I try to define my needs a bit clearer (need more time).

> >  - Thread support.
> 
> Yep, but it seems to be hard in its full generality.  Cooperative
> threads work fine, tho.

Oh, i understand. It just makes things hard if you have to live in an
mutithreaded application (like Apache2).

 Ralf


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel