Ian Eslick <esl...@media.mit.edu> writes: >> > I thought we could just have a single Lisp instance for all the >> > applications we wanted to deploy, but am confused as to how a single >> > Elephant instance could handle multiple stores, one for each >> > application, or better yet, what would be the most advisable >> > deployment model for something like this.
> Probably not the right forum for a detailed discussion of this, > although many Elephant users do deploy it in a web application > environment. I currently use Weblocks for a significant application > and can say that it still has some significant warts, particularly in > the navigation model it has committed to. I think UCW is more mature, > but perhaps less active. This view is more or less correct; UCW has been under development since 2003 or so (with bits of infrastructure being worked on even earlier) and is fairly inactive because the core is more or less /done/. Note that Drew Crampsie refactored the ucw_ajax branch into ucw-core[0] recently. I have a branch[1] and a couple[2] of libraries[3] built atop it intended to rebuild the very much organically grown and unclean standard library found in ucw_ajax. UCW is nice in that the entire system is built as a multilevel protocol that is fairly well defined (if you are ok with docstrings at least--Drew Crampsie is also working on proper documentation for folks who want to customize the RERL). You can more or less make UCW do whatever you want the fits into the model of a Request-Evaluate-Reply-Loop. I have some working (if immature) code for handling Elephant multi-store operation with UCW[4] that allows you to set a default store-controller for a `site' (a group of applications that are to be started and stopped simultaneously) of applications and override the store controller for individual applications (if they inherit from `elephant-store-application-mixin'). I have some example code[5] using this from a site[6] I am working on for a few film student friends (more or less a convenient test application for the other more /interesting/ code I am working on). (Note that the Golognooza site-control stuff has a few warts that are on my TODO to fix--it works for me now and there are a few more pressing tasks). > On Feb 6, 2009, at 6:16 PM, John wrote: >> Our goal is to set up two different layers on Lisp code (maybe >> different machines for each layer). The lower layer will be a Lisp >> image offering a web-service-like API to the middle-layer. The >> middle-layer will contain the actual web framework that will >> interact with Apache and the lower layer. I suppose the lower layer >> could work with something as "simple" as hunchentoot and both layers >> will communicate via internal HTTP. The middle layer will have the >> business-front logic and presentation code and this is where we >> liked weblocks for. We also liked ucw but feel weblocks seems to >> have a more active community. You could use UCW for all layers of the application if you wished. The RERL can be customized easily to provide the behavior you seem to require, and the `standard-component' machinery more or less provides what weblocks does. [0] http://common-lisp.net/project/ucw/repos/ucw-core/ [1] http://unknownlamer.org/darcsweb/browse?r=ucw-core_clinton;a=summary [2] http://unknownlamer.org/darcsweb/browse?r=ucw-forms;a=summary [3] http://unknownlamer.org/darcsweb/browse?r=golgonooza;a=summary [4] http://unknownlamer.org/darcsweb/browse?r=golgonooza;a=headblob;f=/src/elephant/elephant-site.lisp [5] http://unknownlamer.org/darcsweb/browse?r=beesknees;a=headblob;f=/src/site-control.lisp -- Jessie: i thought your beard took the oxygen from the air and made it breathable for you _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
