From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: rm@fabula.de Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_* API extension? [was] scm_* API question Date: Mon, 5 Aug 2002 20:33:06 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <20020805183306.GD19325@www> References: <20020730121436.GA4465@www> <20020730200929.A18106@kiwi.pyrotechnics.com> <20020731100300.GC5661@www> <20020731150602.A32555@kiwi.pyrotechnics.com> <20020801094121.GC7425@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028571685 28316 127.0.0.1 (5 Aug 2002 18:21:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2002 18:21:25 +0000 (UTC) Cc: rm@fabula.de, guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17bmTs-0007Mb-00 for ; Mon, 05 Aug 2002 20:21:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bmUW-0002BV-00; Mon, 05 Aug 2002 14:22:04 -0400 Original-Received: from www.elogos.de ([212.18.192.92]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17bmTv-00025T-00 for ; Mon, 05 Aug 2002 14:21:27 -0400 Original-Received: by www.elogos.de (Postfix, from userid 5001) id 165D41049A6; Mon, 5 Aug 2002 20:33:06 +0200 (CEST) Original-To: Marius Vollmer Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:995 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:995 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