[Seaside] Smalltalk/Squeak/Seaside newbie questions/comments..

[Julian Fitzell]

Hi Rick and welcome,

Rick F. wrote:
> Hi all.. I've not looked at Smalltalk in a good long time -- probably for
> more than 15 years and only then as part of a college languages class so
> I don't really remember anything.  Anyway, I managed to stumble across
> Seaside by accident (it was mentioned on a PHP blog I was reading) and
> it sounds like a really great system for doing web-apps.  I've currently
> got a web-app in development using PHP + Mojavi (an MVC framework),
> Apache and MySQL.  In doing my requisite homework on all things Seaside
> and reading some comments you all had in the not-too-distant past, I see
> a few hurdles that I'm not too sure how to get past -- perhaps you can
> enlighten me or point me in the right direction:
> 
> 1) I have my site running on a web hosting provider using Apache, but
>    notice that most people seem to run the Smalltalk web servers instead
>    of using Apache directly.. I'm not sure I can get my hosting provider
>    to do that -- is there a write up somewhere that shows how to use
>    Squeak/Seaside in an Apache environment -- does it require FastCGI
>    or something else?  I ran across some sort of FastCGI Smalltalk
>    conduit of sorts, but it came with no docs and leaves a newbie like me
>    feeling less than enthused.

Well, sort of.  I think most of us (certainly many of us) use Apache in 
front of the smalltalk VM and use mod_proxy or mod_rewrite to pass 
appropriate requests through to Seaside.  This allows apache to do all 
its fancy redirecting and to serve static content alongside the dynamic 
application.

There is a FastCGI wrapper as I recall, but I'm pretty sure that still 
requires Squeak to be running all the time - you wouldn't really be able 
to maintain all the session state otherwise.  I suppose you could start 
up the image for each request and then save and quit but that sounds 
slooooowwwww.

So yes, you do need an ISP that is willing to let you have a squeak app 
running but it doesn't have to be on a port that is accessible to the 
outside.

> 2) Memory usage -- I've read several comments about memory/performance
>    issues with Squeak in the not too distant past -- had to do with
>    garbage collection if I recall.. What's the chance that this will bite
>    the average web-app on a regular basis and is it still an issue?

I think the thread you are referring to was Avi trying to speed up 
snapshotting so he could use it as part of a persistence scheme.  I 
don't think you're going to find this a major problem if you're storing 
your data in a database.  Really, if you can afford to lose active 
sessions (not the db data) on the offchance that your application might 
crash, you don't need to save the image anyway.  If you're looking for 
5-nines automatic session failover to another image or something, then 
we're not quite there yet. :)

> 3) MySQL -- I've got a database consisting of about 15 tables worth of
>    data that I currently need for my PHP web-app.. I see that a lot of
>    Squeak/Smalltalk users seem to prefer PostgreSQL instead and that
>    the MySQL stuff is a bit dated and perhaps not complete.. Is there
>    any write up on how to use the MySQL driver with Squeak/Seaside
>    and am I going to have license issues with this setup since I saw
>    a note on the Squeak Map indicating some license issue.  In my case,
>    my web-app will not be open-source and will be more commercial in
>    nature.

I know Avi and I used MySQL at some point and as I recall the drivers 
were less fully developed than the Postgres ones, but that's a pretty 
hazy memory.  There is also an ODBC driver so that is another option for 
MySQL access.  Not sure about the license issue...

> 4) On the Web hosting side -- have any of you had problems with 
>    hosting providers not being interested in having you run a Smalltalk
>    based app on their servers since it's "different" than the standard?
>    Has that required you to find a new provider?

I'm sure many hosting providers who only provide PHP+MySQL+apache will 
have problems with Seaside, yes.  There are others that won't, 
particularly those that provide virtual servers for your use.  There 
have been threads on this in the past and I know Netstyle is about to 
offer a Seaside hosting service so I'm sure Adrian will jump in here.

> 5) Squeak vs. VisualWorks Smalltalk -- I've read a few comments here and
>    there indicating that perhaps VisualWorks is faster than Squeak for
>    some operations.. Is this correct and what is the overall thinking
>    of one over the other?  

VisualWorks is probably faster and more stable than Squeak, yes: it's a 
commercial application and a lot of time and money has been put into 
optimizing the VM.  Luckily, if you're careful about how you write your 
code, it will be pretty easily portable.  My general attitude is to 
start with Squeak and move to VisualWorks if and when performance starts 
to become a problem.

> 6) On the VisualWorks side -- If I want to write a commercial app that
>    runs on a web-server on a hosting providers hardware, I gather I
>    would need to install the VM + application on their box to run the
>    app.  In this case, how does the licensing work, and what sort of
>    $$ am I looking at for the cost?  I read through the license docs
>    for VisualWorks and didn't get any warm fuzzies about what model
>    my development goals fit into whether it's some sort of corporate
>    plan or something else.  In my case, my site would be hosted on a
>    single server, but would have potentially hundreds of people using
>    it.. Too bad the makers of VisualWorks are somewhat mysterious about
>    their pricing, etc.

The license isn't as scary as it sounds.  I believe Avi confirmed with 
them that you would need one license per developer of the application 
but that a deployment did not need to be charged for each web user.

> 7) Comparing Seaside to an MVC framework like Mojavi -- Mojavi has the
>    logic separated out by display,business,etc.. I've yet to get too far
>    into a Seaside tutorial, but is Seaside going to be similar in this
>    regard or is it a new paradigm to learn (aside from learning 
>    Smalltalk too)?

Hm... well I guess Components sort of represent the controller and the 
view for most people.  We certainly recommend having a separate model. 
You can also consider WATask to represent a bit of a Controller layer. 
And you could also take CSS to be a big chunk of the View layer, since 
it allows you to completely swap in different looks if you do your HTML 
correctly.

The HTML rendering code (display) would generally all be contained in 
#render* methods on your components.  The application logic would 
generally be contained in the rest of your component and task code. 
Strict business logic could be enforced at the model level or in the 
components depending on how much separation you want.

I've written applications were parts of it used a more pluggable 
view-like layer with the components so this is certainly possible, or 
the renderers themselves are replaceable, or you can use CSS.

I guess you can define the separation several ways.

> I think that's about all of the loaded questions I can think of for now..
> 
> Hopefully I'll get answers to some of the more pertinent ones at least.
> 
> Thanks and Merry Christmas!

You too.  Sounds like you've got a project to keep you busy over the 
holidays now. :D

Let us know if you have any more questions,

Julian

--
Julian Fitzell
julian at beta4.com
Seaside: http://www.seaside.st/