On Sun, 14 May 2000, Gerardo Richarte wrote:
> Hi!
>
> It's late, and I'm tired, and I'm wondering if it's a good idea to
> have a separate server (standard-apache, let's say) to serve uploads
> and uploaded files...
A mixed strategy (i.e., Comanche + something else) does seem like a good
idea at this stage of things. Particularly for lots of static files per
page (like the nav page on ComSwiki). Not that this is a slight against
the (beta, *version 1*, about a *year* old) Comanche. Indeed, when I think
of it, I really have to take my hat off to Bolot and Stephan Pair.
Nevertheless, for example, it still seems that the socket prims are not
the aces, at least on every platform (aside from what tuning can be done
in comanche---e.g., does Comanche support keep-alive connections yet;
there's code, I think, to be gotten from the Camp Smalltalk effort.
> We'll need only to code a small cgi (that I'll gladly do, if this
> is a good idea) to run on the standard server, export files as ftp and
> http (why not?), and change some templates to point to the correct
> places...
I believe the GaTech swikis (some at least) are already using a mixed
strategy to handle, e.g., the nav bar files.
> According to The Paper (STOMP comes to my mind, by I know it's not
> the name... sorry, I can't find it now) this would give a good
> speed-up to Comanche, without loosing to much flexibility... or not?
No, STOMP it is. I don't have the paper before me at the moment, but a
major reason for the dual strategy is handling multiple simultaneous
requests corrected. Once you've done it for that, you may as well do it
for the uploads and downloads ;)
> Is anybody doing this? Comanche and Apacche can run on the same or
> different machine (you can also share file systems if you'd like to).
See above. I'll be working on making Comanch and Apache play more or less
seamlessly together over the next couple of weeks.
(Basically, at http://monkeyfist.com, we want to be able to use Swiki's
and custom comanche apps. But we're not ready to flip the switch all the
way (i.e., our current CMS is a bunch of PHP scripts talking to
MySQL, and I'm the only Squeak/Smalltalk guy, so moving entirely to such a
implementation is going to go by slow stages :)). Originally, we were
going to just run Commanche off a another port (e.g., 8080--this is how
we're handling crit, IIRC), but there are a number of reasons why that's
unsatisfactory for us (mostly because it makes for really yucky permanant
urls and we want people to point into the Comanche server pages). It looks
like mod_redirect will do the job for us. The other strategem is to use
OSProcesses to communicate with a Squeak process---sorta a visualwave
strategy (Bolot, the visualwave docs are very interesting...the do a lot
with load balancing and other server farmish style stuff).
The key to making that work is getting a sensible CGIrequest and
CGIresponse working. Now, assuming that I understand Comanche's current
set of apps, it won't be as simple as popping these in for the http
varients, since converstion is done on a per module basis.
Hmm. Yes. SwikiRequest is a subclass of HttpRequest. Yuck. Wouldn't it be
better to isolate the application specific request/responses from the
*protocal* varients? That way, you'd only need to write conversion methods
when adding a protocal (e.g., SwikiRequest>>fromHttpRequst:,
SwikiRequest>>fromCgiRequest:, SwikiRequest>>fromMorphicEvent,
etc.). Hmm. The numeric classes come to mind again (SwikiResponse
adaptToHttp, or HttpRequest adaptTo: SwikiModule).
Cheers,
Bijan.
