From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: scm_* API extension? [was] scm_* API question Date: 05 Aug 2002 17:08:45 +0200 Sender: guile-devel-admin@gnu.org Message-ID: References: <20020730121436.GA4465@www> <20020730200929.A18106@kiwi.pyrotechnics.com> <20020731100300.GC5661@www> <20020731182124.GD6561@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028560107 16143 127.0.0.1 (5 Aug 2002 15:08:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2002 15:08:27 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17bjT7-0004CE-00 for ; Mon, 05 Aug 2002 17:08:25 +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 17bjTj-0002sO-00; Mon, 05 Aug 2002 11:09:03 -0400 Original-Received: from krusty.dt.e-technik.uni-dortmund.de ([129.217.163.1] helo=mail.dt.e-technik.uni-dortmund.de) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bjTa-0002r5-00 for ; Mon, 05 Aug 2002 11:08:54 -0400 Original-Received: from burns.dt.e-technik.uni-dortmund.de (burns.dt.e-technik.uni-dortmund.de [129.217.163.19]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 11257A3831; Mon, 5 Aug 2002 17:08:52 +0200 (CEST) Original-Received: by burns.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id 85E2AF431; Mon, 5 Aug 2002 17:08:45 +0200 (CEST) Original-To: rm@fabula.de In-Reply-To: <20020731182124.GD6561@www> Original-Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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:979 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:979 rm@fabula.de writes: > > Why do you want to perform module system operations from C? Maybe > > there is a more elegant way. > > Ok this is for my current (frankensteinish) hacking with Dave's mod_guile: > i'm working on implementing a mod_guile mode in which URLs get mapped to > so-called 'handlers' in modules - meaning i (ab?)use the hierarchical module > space a namespace enclosures. That sounds rather reasonable to me. But do you need to invoke 'use-modules' for this? What I would probably do is to have a single Scheme function that gets called from C, and perform all the dispatching in Scheme. That function would be called with different arguments for different s. I suppose, all Apache can really handle in its configuration file are strings. So I would make my Scheme function take a string as its argument. When the function wants to interpret that string as a Scheme form, it can do so. (Calling 'read' from Scheme is no less efficient than calling it from C, but more convenient.) Maybe I would even require the Scheme code to register the dispatching function with the C code before it can be used. That way, the C code is completely independent from the Scheme code and the interactions between the too are not via magic names but by explicit API calls. > I'll also plan to add something like > > GuileBind a-symbol '(arbitrary (guile data) structure) > > i.e. i want guile to 'read' from the configuration file and bind > 'a-symbol' to whatever was read. I think I would pass extra information via the handler callback, not as a variable, but of course I can't say whether that will be feasible in your case. > BTW, one reasons i do use the module system is the impicit cacheing i get: > a module gets loaded only once, and that does make a difference in response > time compared to the initial 'eval a file per request' aproach of mod_guile. I see. mod_guile should probably have a 'call a function per request' kind of model. That is just as flexible but does not have to be slow. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel