[Seaside] updateRoot: Weirdness

Jason Johnson jbjohns at libsource.com
Fri Jul 20 09:46:29 UTC 2007

Keith, I have never said this to you before (or thought it about you as 
far as I recall) but you are off-base here.  Seaside doesn't serve files 
because it isn't a web server.  It can't even serve itself, it relies on 
a web server to do that.  Now I agree about apache, I don't use it 
either and I don't want to.  I use Commanche to serve Seaside and this 
web server can easily serve files as well by just setting it's state 
correctly (configuration some might say).  You can find how to do this 
on David Shaffer's site [1], among other places.  Rather then 
duplicating functionality by having Seaside *also* serve files, why not 
use the thing you have to use anyway: your Smalltalk web server 
(Commanche, Swazoo, I don't know what else we have)?  It will have (or 
at least can) have a lot more options and flexibility.  It's already 
there, and any advances made to the web servers you get for free.

I have used Commanche this way from the start, I made a directory in my 
image directory called "website" or "www" or some such, setup Commanche 
to use it as described on David's site and put all my files there.  And 
everything is responsible for what it should be:  Seaside does all the 
application work and generates HTML, the web server serves it and so 
on.  Why would you want Seaside to duplicate this role?  Would you 
expect Morphic to also serve files?  Or Monticello?

Now the reason some people on her recommend fighting with apache is 
because they are concerned about speed of serving the files.  Personally 
I wish the teams making these web servers would see that as a challenge 
and try to get their speed compatible enough to be the choice 90% of the 
time for production [2].  I think this would be achievable at least on 
Linux by making a plugin for the sendfile system call, and perhaps make 
it async if it isn't already.  Using sendfile is one of the ways lighttp 
beats apache in speed.

[2] I know people say Commanche isn't maintained, but it's open source 
no?  What stops us from just making a "Commanche 2" project on 
SqueakSource, upload all the current code and fork?  If it has anything 
Swazoo doesn't anyway (i.e. if it's worthwhile to do so).

Keith Hodges wrote:
> I don't think that  everyone is interested in being an expert at 
> configuring wierdo linux technologies. I myself have no intention of 
> ever having to write apache rewrite rules. If I ever have to then I 
> figure something is wrong.
> Why do I think this way you might ask. It is simple, I am a mac user!
> Not that I cant do the "hard" stuff, I used to program my PC's in C 
> back in '85 and mc code before that.
> The fact is that I don't want to.
> I don't know why everything is so hard. When you collect your images 
> together, when you edit your images where are they? On disk, so where 
> should you be able to serve them from by default. Yes thats right ON 
> If you are fine tuning your site, editing you images what don't you 
> want the browser to do? Thats right you don't want it to cache the 
> images! Can seaside do this out of the box no it can't! Never mind 
> accessing databases, seaside cant even serve files.
> Moving the file in-image is an optimization, and its quite nice for 
> distributing a pre-configured image without lots of supporting files, 
> but its not the simplest thing to configure or use. Throwing your 
> files into a directory or a directory hierarchy is. And seaside cant 
> handle that, despite, as I was told recently trying to embody the 
> 80-20 rule, that is supporting the majority of what users want to 
> achieve.
> So in terms of lowering the bar for newbies some things are basically 
> obvious, but seaside has acquired an "elitist" approach. It appears 
> that some things (like serving files) are beneath it, and "best left 
> to apache". So it turns out that due to this elitism, seaside cant 
> even do the basics out of the box. The purist mentality doesnt allow 
> for the "seaside does what it does, and does it well" to be poluted by 
> compromise positions which would make things more flexible and 
> therefore perhaps more broadly usable. Serving files is but one 
> example, using cookies for day to day site things is another, this 
> facility almost disappeared from 2.8a unnoticed.
> Now I would like to be able to rectify this situation, but I have a 
> distinct disadvantage, I don't write perfect code, I throw something 
> together which does the job, I need others with different skills to 
> refine and hone the result to perfection.
> So as it happens I have on numerous occasions attempted to submit code 
> which addresses some of these (imho) shortfalls. And time and time 
> again the purists reject much of what I have offered out of hand. For 
> various reasons, some of them good reasons. Nevertheless I got tired 
> of the continuous negative attitude that comes out in this "protecting 
> the purity" of seaside.
> This has resulted in me making a complete ass of myself by loosing my 
> rag (fortunately in private) at the maintainers. I have apologized, 
> and if you have noticed that the seaside repository is now read only, 
> thats probably all my fault that I pissed off the maintainers and I 
> apologize to them and also to the community for that.
> But lets examine this a little bit, one example.
> Seaside configuration attributes are organized into groups. So the 
> function "tell me if this application has the configuration group 
> named x" (so I can add a dispatcher plugin to it). This function is an 
> accessor into private information encapsulated within the seaside 
> kernel so to speak. So in order to make this useful as a feature, 
> whose responsibility would it be to provide an accessor? I would say 
> the package that implements the feature should expose enough of that 
> feature in a public api so as to be useful to users who want to use 
> it. So I suggest #hasGroupNamed: accessor  to match its existing 
> counterpart #hasAttributeNamed:
> The objection I am given is: "This is dangerous". Why? Because it has 
> no users within the seaside core package, and having no users it is 
> fragile and might break or be removed without anyone noticing. Well 
> hang on, isnt that obvious! It isnt in the base package 'yet' so of 
> course it hasn't got any users, its whole purpose is to be a public 
> API so that clients and extensions to the base package can use it. Its 
> reason for being that is to support users external to the core, not 
> internal to the core, the internals probably dont need it since they 
> can access the value directly etc. So somehow we have this statement 
> of law which says "No public api shall be exposed which is not used 
> inside the grey-box of the core, which incidentally doesnt need a 
> public api anyway".
> So what if it does break? Well if it doesnt have any users inside the 
> core seaside package, then who cares. Its not dangerous at all, if it 
> breaks its not going to ruin anyones day. Ok so I, with three users of 
> this api might miss it and flag if it becomes broken. But dangerous it 
> is NOT.
> This really got my goat I am afraid, I attempted to put this accessor 
> into the seaside repository 6 times or more. And it still hasnt made 
> it past the idealistic police. Now I am not writing code or uploading 
> to monticello for my health. Can you wonder why I got a little peeved.
> So if you are wondering why seaside doesnt make progress in attracting 
> broader appeal, one possible answer is that the maintainers have a 
> very narrow and purist perspective. Which is worthwhile, and serves a 
> purpose to make seaside better in a certain focussed way, just not in 
> the way that will broaden seaside's appeal (imnsho).
> So lets turn to the question at hand, serving files. What would it 
> take to add this to seaside.
> 1 Method thats all! Where is it? Not there? Why not? because I guess 
> serving files must be in the 20 of the 80/20 mentioned earlier. Who 
> decides this? Well someone who likes configuring apache I guess.
> So in a three method varient a) subclass FileLibrary add an instVar 
> fileNames and load it up with any resources you want to serve in-image 
> as defaults which the files can then override.
> the methods:
> WAFileBasedLibrary-initialize
>    fileNames := self libraryDirectory fileNames
> WAFileBasedLibrary-libraryDirectory
> ^FileDirectory default directoryNamed: 'resources'
> WAFileBasedLibrary-documentAt: aFilename ifAbsent: aBlock
>      | doc |
>    (fileNames includes: aFilename)
>        ifFalse: [ ^ super documentAt: aFilename ifAbsent: aBlock ].
>    doc := (WACachedDocument
>            fileName:  (self libraryDirectory pathName, FileDirectory 
> slash , aFilename)) asMIMEDocument.
>     ^  WAResponse
>            document: doc
>            mimeType: doc mimeType
> Bingo, now that wasn't hard was it, throw any files you want to serve 
> into 'resources' directory and you are away.
> best regards
> Keith
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list