About Seaside 3.0

Philippe,

You are missing the point.  So what if port 80 is difficult to use - use
another one.  The idea is to offer a system administrator an interface
to check the status and make small changes to what is essentially an
appliance.  The fewer things that could potentially be mis-configured,
the better.

In the type of work I do, I will take simple, slow, and encrypted any
day.  I am not "building web sites" in this situation, so the rules to
which you cling do not apply.  That said, I will want your guidance for
the few machines I envision setting up that will be "web sites" in the
more typical sense.  And yes, they will be based on Apache.


"Apache will still be running when your image is long gone and can serve
a nice 503 page".  That's scary.  Where is the problem?  Is it Seaside,
or dialect-specific?  I am accustomed to my Smalltalk images running
strong when the OS is starting to crumble around them.

Bill





==================================
Philippe Marschall philippe.marschall at gmail.com
Sun Jul 13 06:59:56 UTC 2008

    * Previous message: [Seaside] About Seaside 3.0
    * Next message: [Seaside] About Seaside 3.0
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

You will have Apache as a frontend anyway because:
- there is to my knowledge no way to run Squeak on a privileged port
without giving it root rights
- there is to my knowledge no way to generate Apache style access logs
with Kom. The ones that can be read by a whole lot of tools like
AWStats.
- Apache will still be running when your image is long gone and can
serve a nice 503 page
- less bitching with your admin and security people

Second, HTTPS/SSL really eats CPU cycles. Thats why a lot of sites
like GMail use it only for login and then switch back to HTTP.

Once you have accepted that there will always be an Apache frontend
implementing a web server in Smalltalk doesn't make a whole lot of
sense anymore. Something like an AJP connector will do fine.

Cheers
Philippe




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/7/13 Bill Schwab <[hidden email]>:
> Philippe,
>
> You are missing the point.  So what if port 80 is difficult to use - use
> another one.  The idea is to offer a system administrator an interface
> to check the status and make small changes to what is essentially an
> appliance.  The fewer things that could potentially be mis-configured,
> the better.

Nope sorry. HTTP is port 80 HTTPS is port 443. Anything else just
causes trouble.

> In the type of work I do, I will take simple, slow, and encrypted any
> day.  I am not "building web sites" in this situation, so the rules to
> which you cling do not apply.  That said, I will want your guidance for
> the few machines I envision setting up that will be "web sites" in the
> more typical sense.  And yes, they will be based on Apache.
>
>
> "Apache will still be running when your image is long gone and can serve
> a nice 503 page". That's scary.

No, that's very reassuring.

> Where is the problem?  Is it Seaside,
> or dialect-specific?

Smalltalk images do a lot of things as a consequence there are very
lot of things that can go wrong. Smalltalk images were never
engineered for reliability. One rouge thread can take down the whole
image. Contrast that to Apache which was engineered for reliability.
An Apache module can segmentation fault and Apache keeps running.
Compare that to the Squeak image where the UI event thread can
interact in very interesting ways with the GC.

> I am accustomed to my Smalltalk images running
> strong when the OS is starting to crumble around them.

Good for you.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I haven't been following the details of what Bill is proposing very
carefully but I can see the point he's trying to make.

Many people may have internal tools written in Seaside. I have
considered writing a web interface for user management at my current
job. It would essentially be a tool for administrators and help desk
staff to perform operations on accounts. Such an application would
have a half dozen total users, maybe 2 concurrent at maximum. Given
the sensitivity of some of the information, however, we would
certainly want the connection encrypted.

Such an application wouldn't need any of the power or reliability of
Apache really and it certainly isn't a problem for it to be running on
an alternate port (many of our existing administrative web
interfaces--including vendor-suplied ones--run on alternate ports).

As long as Apache is the easiest way to set this up, it's not the end
of the world for me to do so. But if there was a solution available
that didn't require the extra infrastructure I would certainly
consider using it. Obviously this isn't going to be the best scaling
architecture any time soon but that's ok.

I also understand the desire not to have everything re-implemented
(and then unmaintained) in Smalltalk. But if there's an itch that
someone wants to scratch and enough users that it ends up being
maintained, great.

Julian
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I understand what you mean by reliability (running 20 servers and  
killing the ones not running)
but pay attention, squeak vms is not = to smalltalk vms.


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/7/13 stephane ducasse <[hidden email]>:
> I understand what you mean by reliability (running 20 servers and killing
> the ones not running)

No, I mean the following:
For each request Seaside forks a special "restricted process" which
has the following properties
- it is not allowed to allocate more than 2 MB of heap memory
- it is not allowed to use up more than 10 secs of CPU time (not
counting IO wait and GC)
- it is lightweight like normal Smalltalk processes

In addation on a image level there are the following properties:
- instances of WASession are not allowed to take up more than 100 MB total
- we are not allowed to have more than 10'000 live instances of WASession
- we are not allowed to have more than 20 concurrent Seaside requests
-> we don't have more then 20 restricted processes

Of course all numbers are subject to tweaking.

> but pay attention, squeak vms is not = to smalltalk vms.

Yes, gems are indeed very different and provide also other nice
features like session replication.

Cheers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall wrote:
Excuse my ignorance, but is Squeak Seaside now doing all of the above?

And if so, as of which version?

Thanks!

Nevin

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/7/14 Nevin Pratt <[hidden email]>:
No, it's doing not one of them and that's the whole point.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside