[Seaside] updateRoot: Weirdness

Jason Johnson jbjohns at libsource.com
Fri Jul 20 12:33:37 UTC 2007

Keith Hodges wrote:
> Dear Jason,
>> 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
> We are talking about 2 different things. There is 'seaside' the html 
> generator with bells on. And 'Seaside' the solution. These are two 
> different things.

Well, Seaside the "module" or "component" has, itself, two parts: the 
HTML generator API you describe, and the machinery to make the HTTP 
protocol more transparent.  I think I know what you mean though; there 
is also what you call the "Seaside Solution" which includes which ever 
HTTP Server you happen to be using.  Sorry I didn't get that from your 
first email.

And I do think myself that it would be helpful to add some pages for 
setting up the different configurations.

> I am complaining that 'Seaside the solution', doesn't have some 
> basics, and you are indicating that my criticism is unfounded because 
> 'seaside' the the html generator is not a file serving web server.

No, I see Seaside as more then "an HTML generator", that's just one 
piece of it.  But it is true that I did not understand you meant the 
over all solution which includes the web server.  For me, coming from an 
Apache background, the two things (Seaside and the web server that 
actually serves it) are two different things.
> Indeed 'Seaside' the solution, if you look closely at the (as far as I 
> know undocumented) api WAKom probably does have all the pieces that 
> are needed but, it appears that you are on your own when it comes to 
> pulling all of these pieces together coherently.

Yes, this part could certainly use work.  Dave has done some work in 
this direction, and I have suggested going "whole hog" and putting an 
HTML configuration page in each server like Seaside itself has, so that 
the configuration is easier for everyone.

> My overall point is that 'seaside' exists as part of bigger solution 
> and so needs integrating with other things. It is not apparent to me 
> that 'seaside' the code is being developed with 'Seaside the solution' 
> in mind. I think we lack vision as to what 'seaside the solution 
> actually (should) consists of.'

There is also something to be said for loose coupling. :)  IMO, any 
Smalltalk web server should have a way to configure it from the web 
pages it serves, because it can.  Apache shows up a welcome page and 
points you at documentation for configuring the server.  They do this 
because it would be difficult to do anything more.  But since the ST web 
servers aren't shackled by configuration files we can (and should IMO) 
do more.

And I think that Seaside's "integration" should simply be to provide a 
link to where this configuration location would be.  Note that while you 
consider the web servers part of the "Seaside solution", they themselves 
are more then that.  They could be used to just have an easy to set up 
and "I can watch/learn how it works" web server that only serves static 
pages, create your own little applications that have nothing to do with 
Seaside, or serve some other framework.

> A worked example to try and explain exactly what I mean.  I have some 
> resources being served by MyFileLibrary,
> In my html generation code I use
> html image url: (MyFileLibrary / #logoPng)
> This appears to be the most concise mechanism of referencing a served 
> resource.

Personally what I do is, I have my Commanche web server set up so that / 
is the website directory and /myapp is where my seaside/pier application 
lives.  In my code the above would look like:

html image url: '/images/logo.png'

I like this solution because I don't have to touch code anymore if 
things change.  If the directory moves to another location I can change 
the directory that Commanche has for / or /images, and if it is on a 
totally other server then I just have to put an alias in to say that 
/images actually means e.g. http://some.other.server/resources/images.  
For me this feels like a powerful, as well as quick/simple for me to set 
up, way of running my site.

This is what I was talking about with having more flexibility using the 
web server, then making code in (what I call) Seaside.  If you write the 
code you are describing below, won't you just end up duplicating this 

> So now I configure uncle bobs webserver, comanche whatever to serve my 
> files instead... and the mechanism for switching to this better 
> solution is?
> a) write my own class to generate urls which target the new server. 
> UBFileLibrary-#/
> Replace all references to MyFileLibrary / fileSelector with 
> UBFileLibrary, or perhaps put the hard wired urls in instead.
> Thats not really a solution (user/author/builder level) thats coding 
> (programmer/architect level).
> Ok, so I want to write UBFileLibrary to reference my externally served 
> files, where do I start. How much help do I have from 'seaside' 
> itself. Is there an object somewhere I can simply change a 
> configuration setting on to point to my new file server, or is some 
> coding necessary? Ok if I am going to code something up who do I 
> subclass. WAFileLibrary, or WALibrary, or in worst case start from 
> scratch from Object?
> Ok if I subclass WAFileLibrary... the urls generated are hardwired to 
> the class name! I have no choice my files have to be served at 
> http://samehost/<entryPoint>/UBFileLibrary/logo.gif etc. This seems a 
> little restrictive, if I want to change it, I would have to change the 
> whole WALibrary implementation not to use the class name everywhere.
> Lets say I am at a university and they have a set up where I can put 
> all my own website stuff on the public servers at 
> myuniversity.ac.uk/~myaccount/logo.gif etc ? In that case I am 
> definitely beyond the remit of any of the WALibrary classes, I have to 
> start from scratch using Object, or put hard wired urls in my code.
> This leads me to my conclusion, apart from WAFileLibrary which is 
> extremely limited in scope.
> 'Seaside the solution'  does not have any configurable solution for 
> serving files/resources, and neither does 'seaside' the html generator 
> have any solution for integrating with such a solution should it exist.
> So yes I stand by my observation that 'Seaside' lacks some basics of 
> which file serving is the primary example, and 'seaside' is not 
> providing any configurable hooks that could lead me to conclude it 
> supports serving files either.

Based on what I said above, it appears we disagree on this. :)  But 
certainly it could use some work so that the interface is a nice web 
page instead of the ST workspace like it is now (though I think there is 
a morphic interface for Commanche).

> best regards
> Keith

More information about the Seaside mailing list