JD, 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.
Another option to look at is the core server project yet, although it is integrated with a different persistent store model. Ian On Feb 6, 2009, at 6:16 PM, John wrote: > Thanks for the prompt response. We hadn't actually looked at any web > frameworks per se. Our intention is not to develop our own. Instead > have read up a little on weblocks, ucw, kpax, kanamit, and > hunchentoot. > > 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. > > I guess we could just as well use weblocks for the lower layer, but > that may just be too much for what's really needed off it. > > I could ask which you would recommend but that probably doesn't > belong in this list and it also probably depends on the actual goal > and design of the application. It may sound as if this whole setup > seems like an overkill for such simple application, but the > applications I mentioned were just mere examples. Our intention is > to develop much more "mission-critical" applications... but we still > have a lot to learn. > > So, assuming we're only concentrating on the lower-layer, I think > the recommendation to dynamically bind *store-controller* for each > request/thread depending on the app may sound like the best approach. > > Your other suggestion of deploying them on multiple machines is very > valid. The only reason we don't consider that is strictly cost > reasons. I know you can get a shared hosting account where you can > install Lisp for about $9/month, but our corporate requirements for > IT systems require us to use much more expensive environments, and > so we are trying to re-use as much as possible the resources given. > > Thanks again, > JD > > On Fri, Feb 6, 2009 at 5:08 PM, Ian Eslick <esl...@media.mit.edu> > wrote: > The answer to this depends on the web framework you are using. > > A simple answer is to dynamically bind *store-controller* for each app > for each request/thread. Since each thread will have its own binding, > each is tied to a particular application. > > If you put all your database IO into a with-transaction body you can > use the :store-controller argument to pass in the current store which > will then be bound to *store-controller* in the body of the with- > transaction form. > > If you use a higher level web framework like weblocks, it already > directs through its own store abstraction and supports multiple > webapps, each with a different store which will then handle all the > *store-controller* stuff for you if you don't violate the abstraction > (which you will probably want to do, however). > > If you are rolling your own web framework, then I'd just implement > abstractions around the database operations which know what app is > running and directly supplies the appropriate store-controller to the > functions requiring/supporting :sc or :store-controller arguments. > > However, if each of your apps is that independent, why not just put > one per server and avoid the complexity? > > Ian > > On Feb 6, 2009, at 4:31 PM, John wrote: > > > Since our interest is to use Lisp and Elephant to create web > > applications, I'd like to request some deployment advise for Lisp > > and/or Elephant. > > > > Our intention is to have Apache in front of a Lisp image running > > some web server, where Apache will simply allow us to proxy/load- > > balance traffic. Maybe we could have Lisp running in a large machine > > "fronted" by multiple Apache servers. > > > > Imagine we want to offer to separate services. One would allow > > people to maintain a list of friends and contacts (AKA a contact > > database) and the other will allow people to maintain a To-Do List. > > > > We thought we could have a single Lisp instance listen for requests > > based on URL or entry points. Each application would have its own > > data store. By default, Elephant functions use *store-controller* to > > connect to the data store. However, since we'll have multiple data > > stores, the question is: should we be rebinding *store-controller* > > for each application, pass a specific :sc argument to all our > > function calls, or simply have multiple Lisp instances running and > > listening on different ports for each application? > > > > 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. > > > > Thanks in advanced, > > JD > > _______________________________________________ > > elephant-devel site list > > elephant-devel@common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
