[Seaside] So where is the "release" version of 3.7? - while we're
on the subject
stephane.ducasse at free.fr
Wed Feb 28 15:13:42 UTC 2007
Gemstone+ seaside could be a killing solution (if pricing support
tiny developers) to play against LAMP and other
approaches. But I guess that the prices will not be sustainable for
Pay attention that there is a MC2 version in the drawer.
On 28 févr. 07, at 02:48, Dale Henrichs wrote:
> As a matter of fact, we are getting real close to taking a serious
> look at porting SqueakSource to Gemstone.
> We are interested in taking an existing Seaside application and
> porting it to Gemstone, to get a better feel for how hard/easy it
> will be and since we are planning on having a SqueakSource site for
> Gemstone-specific code, SqueakSource would be a natural choice. On
> top of that I am intrigued by the idea of providing a Gemstone-
> based repository for Monticello, so again SqueakSource would be the
> natural application for leveraging a Gemstone-based monticello
> It is more likely that we will base our port on the existing set of
> packages for SqueakSource, but the lessons we learn from that port
> can be applied to anything done for 2.7.
> Philippe Marschall wrote:
>> 2007/2/27, Dale Henrichs <dale.henrichs at gemstone.com>:
>>> Not to complicate the discussion too much, but...
>>> As many of you already know, we are porting Seaside to Gemstone.
>>> As part
>>> of that effort we have decided to port Monticello to Gemstone as
>>> We want to make it easy for folks to move their applications from a
>>> Squeak image to a Gemstone image and Monticello seems to be a
>>> natural fit.
>>> Of course, this adds an extra dimension to the naming issue:
>>> because of
>>> platform differences, there will be some monticello packages that
>>> Gemstone specific (today _all_ monticello packages are Squeak
>>> The fundamental question is should the platform be encoded in the
>>> (i.e., Package_gemstone.branch-author.99) or not (implied by the
>>> For example, I have a version of seaside stored in
>>> Seaside2.6g-dkh.18.mcz. This version contains Squeak source and
>>> has as
>>> an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent
>>> that contains the Gemstone source.
>>> After the discussion of the last few days, I assume that the squeak
>>> version should be stored in a package called Seaside2.6a3-dkh.
>>> since it contains code that is rooted in the 6a3 branch.
>>> My question is what should the version of the Gemstone code be
>>> It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz,
>>> but will
>>> contain Gemstone specific code.
>>> BTW, we already plan on hosting a Gemstone SqueakSource site, so
>>> that we
>>> don't pollute the site with gemstone-specific packages.
>> Will that SqueakSource run on Gemstone by chance? You see, we are
>> looking into porting SqueakSource to Seaside 2.7 (which would
>> mean rewriting the whole UI) and the model is quite simple (only 12
>> classes). Additionally we are looking for some real persistence
>> solution. So if you need some kind of demo application .... ;)
>>> I think that the version name should share a common branch and
>>> name with a platform designator...
>>> What do you folks think?
>>> Seaside mailing list
>>> Seaside at lists.squeakfoundation.org
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside