[Seaside] session reference

[Stephen Pair]

Ah, I see now why you are so concerned about dependencies.

The transparent transactional control over state (which the parser
enhancements enable) is a slippery slope that ultimately leads to a
modified VM.  And that is not likely something that will ever be
possible in a commercial VM (although, if its usefulness is proven in
Squeak, it might be adopted elsewhere).  VisualWorks and VisualAge both
have an immutability bit, which is a first step in that direction; and
Eliot did mention that he liked the StateDictionary I was using in the
Chango VM.

But, back to the question at hand...portability.

I think that you need to make a decision on that front sooner rather
than later as it will affect many decisions that you'll make.
Portability to other dialects is nice, but there are also many benefits
in being more intimately tied to the Squeak platform.  Not only do you
need to decide whether or not to be portable, but also how you will
achieve portability...here are two extremes:

A) Do what SUnit did: build an entire portability layer
B) Do what I did with Kats: I didn't do any work to make it portable and
took the approach that I'd port it when someone was willing to pay me to
port it...which I did.  The VisualAge port of Kats ended up being almost
trivial even though I never designed Kats with portability in mind.

With Kats, the 45 SUnit tests were actually a huge win for porting.  I
loaded Kats into VA, and starting one by one through the SUnit tests.  I
took maybe 1 - 2 days at most to port Kats (sans UI).  I built a VA
specific UI in another couple of days.  As you can imagine, the most
time consuming part of the port was porting the IvapParser.  The rest
was mostly method name differences, or slight differences in behavior.

Anyway, *I* would prefer a Seaside that is designed specifically for
Squeak, with lots of SUnits tests, and with no portability crumbs
littering it.

Also, you could position Seaside as a thing that stands on its own
(independent of any Smalltalk implementation; but which happens to use
Squeak).  So, when you are using "Seaside", you are using "Seaside", not
"Squeak+Seaside".

- Stephen

> -----Original Message-----
> From: seaside-admin@lists.squeakfoundation.org 
> [mailto:seaside-admin@lists.squeakfoundation.org] On Behalf 
> Of Avi Bryant
> Sent: Saturday, December 07, 2002 3:55 AM
> To: seaside@lists.squeakfoundation.org
> Subject: RE: [Seaside] session reference
> 
> 
> 
> On Fri, 6 Dec 2002, Stephen Pair wrote:
> 
> > Are you being too concerned about dependencies?  After all, you can 
> > bundle up everything you depend on into a single 
> installable thing.  
> > No big deal.
> 
> No big deal for Squeak, maybe.  But I'd like to keep Seaside 
> relatively portable (at least to the dialects that can 
> support callCC ;), and depending on modifications to Process 
> doesn't help.  Neither does needing compiler hacks, of 
> course, and I'm wondering whether the IVAP stuff Seaside does 
> is actually worthwhile.  Since it's only used for components, 
> and only needed for a subset of their state, I wonder how 
> onerous using an explicit 'state' dictionary would be - that 
> would also give you easier control over what state was copied 
> and what wasn't.  Opinions?
> 
> 
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>