gmane.comp.lang.smalltalk.squeak.seaside

Bill Schwab | 13 Jul 16:19

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:

(Continue reading)

headers

Philippe Marschall | 13 Jul 16:57

Re: About Seaside 3.0

2008/7/13 Bill Schwab <BSchwab <at> anest.ufl.edu>:
> 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

(Continue reading)

headers

Julian Fitzell | 13 Jul 17:16

Re: About Seaside 3.0

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

headers

stephane ducasse | 13 Jul 21:46

Re: About Seaside 3.0

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.

>>
>>
>
> 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
> seaside <at> lists.squeakfoundation.org

(Continue reading)

headers

Philippe Marschall | 13 Jul 22:44

Re: About Seaside 3.0

2008/7/13 stephane ducasse <stephane.ducasse <at> free.fr>:
> 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

>>>
>>>

(Continue reading)

headers

Nevin Pratt | 14 Jul 21:52

Re: About Seaside 3.0

Philippe Marschall wrote:
>
> 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.
>
>
>   

Excuse my ignorance, but is Squeak Seaside now doing all of the above?

And if so, as of which version?

Thanks!

Nevin

headers

Philippe Marschall | 14 Jul 22:26

Re: About Seaside 3.0

2008/7/14 Nevin Pratt <nevin <at> bountifulbaby.com>:
> Philippe Marschall wrote:
>>
>> 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.
>>
>>
>>
>
> Excuse my ignorance, but is Squeak Seaside now doing all of the above?

No, it's doing not one of them and that's the whole point.

Cheers
Philippe