[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_* API extension? [was] scm_* API question
From: |
rm |
Subject: |
Re: scm_* API extension? [was] scm_* API question |
Date: |
Mon, 5 Aug 2002 20:33:06 +0200 |
User-agent: |
Mutt/1.3.24i |
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