[Seaside] Re: What's the (technical) purpose of adding t/seaside/ to the path

[Michael Lucas-Smith]

Jason Johnson wrote:
> I think I'm a little confused here.  /seaside is only in the path 
> because that's the location you configured Seaside to live on the web 
> server no?  If you want it somewhere else can't you just do something 
> like:
>
> ma := ModuleAssembly core.
> seaside := WAKom default.
> ma alias: '/my/other/location' to: [ma addPlug: [:request | seaside 
> process: request ] ].
>
It's different for every web server - WebToolKit, Swazoo, Kom, 
Opentalk-HTTP, Whatever Dolphin has. So it's kinda hard to write a 
tutorial for it that covers all the Seaside versions out there.

It's also a kind of random piece of voodoo for a beginner coming on to 
the scene don't you think?
> Kinda depends who is your target. For anything serious or commercial
> is setting up and Apache a really an issue? Srsly?
Well I know Cincom customers punished the previous web team enough that 
they have a whole mapping and aliasing engine built in to WebToolKit for 
exactly these issues - I agree, using Apache is a nice way to avoid 
having to write the code yourself, although not having to write it in 
the first place is even better.
>
> The more serious deployment barrier I see is how do you deploy static
> resources like images and pictures?
We set up a Resource class that had a base URL that was pointing to 
Apache - in that respect, the Seaside program was never mounted on a URL 
that it wasn't going to be on (except for host:port) and the images 
could move around with a Configuration parameter. It also meant that we 
could do what Boris does - use resources in-image and then move them off 
to another server when we deploy.
> How do you manage dependencies?
It's all Smalltalk code so the flick of a seaside configuration variable 
is no biggy.
> How do you continuously integrate? 
Same as you always do.

I think the /seaside URL is a bit of a perception problem for new users 
coming in. They expect to have control of the URL mapping space - in 
fact, it looks pretty good when you see that you can register your class 
with a name and that the URL to invoke your application is that URL - 
except for this /seaside thing on the front.

I like the advertising it gives the project - but I can't see anyone 
wanting to ever deploy with /seaside in their URL for a real app - which 
means just about everyone is going to want to remap it or reconfigure it 
to not have it. So.. my thoughts still point toward not having it in the 
first place to remove the issue completely.

Michael
>
> ?  Looks quite easy to change to me.
>
> Philippe Marschall wrote:
>> 2007/7/20, Michael Lucas-Smith <mlucas-smith at cincom.com>:
>>> Is the general consensus that people would rather the /seaside/ wasn't
>>> part of the default URL?
>>>
>>> If we change this - will anyone have a problem?
>>
>> You mean besides updating all the tutorials ever written and all the
>> server configurations?
>>
>> Philippe
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside