[elephant-devel] Advice on multiple deploying multiple applications/repositories

[Clinton Ebadi]

Ian Eslick <eslick at 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