[Seaside-dev] Seaside31 comments
Dale Henrichs
dhenrich at vmware.com
Thu May 17 17:44:25 UTC 2012
Philippe,
If you have any questions at all don't hesitate to drop me a line...
Dale
----- Original Message -----
| From: "Philippe Marschall" <philippe.marschall at gmail.com>
| To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
| Sent: Thursday, May 17, 2012 2:45:36 AM
| Subject: Re: [Seaside-dev] Seaside31 comments
|
| On Tue, May 15, 2012 at 1:56 AM, Dale Henrichs <dhenrich at vmware.com>
| wrote:
| > Philippe,
| >
| > These are my unfiltered comments on the configurations. I want you
| > to take the comments with a grain of salt, because my comments are
| > intended to inform not explicitly criticize. I'll make remarks in
| > detail, but I don't think it is worth it for you to make detailed
| > responses. I don't intend on spending a lot of time
| > explaining/defending my comments, unless something doesn't make
| > sense to you or you feel strongly ... those are the areas that are
| > worth discussing in my opinon.
| >
| > There's lots of wiggle room in defining specs so there aren't too
| > many black and white issues ... if the configuration validates
| > cleanly it should be good to go.
| >
| > I didn't finish looking at all of the specs, but I think I've hit
| > enough of the highlights to get the ball rolling...
| >
| > Dale
| >
| > ------------General----------------------------------
| >
| > 1. Eventually you will have one package per configuration, instead
| > of all the configurations in one package.
| >
| > ------------ConfigurationOfSeaside31----------------------------------
| >
| > 1. #seaside304DoIts is probably not needed in 31. Include only if
| > you have proven that you need it.
| >
| > 2. you've included a bunch of GemStone packages ... are those know
| > to work or just included from 3.0?
| >
| > 3. The #project method has extra cruft that is no longer needed ...
| > replace with MetacelloBaseConfiguration>>project.
| >
| > 4. Strip the class side development support category... I think
| > there is better toolbox support for the operations ... keep the
| > #validate method.
| >
| > 5. it's worth looking at Versionner to see if it performs the
| > require development operations. Let Juan know if it Versionner
| > needs work...
| >
| > 6. Do you plan on continued support of Swazoo in 3.1?
| >
| > 7. The 'default' group loads 'Core' and 'Tests' are you sure that
| > you want to continue with that? Starting from a blank slate, I
| > would do things differently for Seaside3.1:
| > - 'Base' renamed to 'Core' with tests following suit
| > - 'default' includes 'Core' only
| > - 'Production' to include the "tools recommended for production"
| > - Move 'Seaside-HTML5' 'Seaside-Tools-Web' 'Seaside-Swazoo'
| > 'Seaside-Adaptors-Swazoo' 'Seaside-Tools-OmniBrowser'
| > 'Seaside-FileSystem' to a separate configuration (tests too)
| >
| > 8. Actually, I'd create ConfigurationOfSeasideCore31 ... it would
| > include all of the packages in the 'Base' package. Most of the
| > packages that depend upon Seaside would reference
| > ConfigurationOfSeasideCore31. 'default' group for this
| > configuration should just be the non-test packages.
| >
| > 9. The ConfigurationOfSeaside31 would then include the packages
| > that are in the current ConfigurationOfSeaside31, but not in
| > ConfigurationOfSeasideCore31...this would probably make it
| > possible to do away with the *commonBaseline: method (created
| > because of 256 literal limit). Group definitions as follows:
| >
| > - 'default' includes the "kitchen sink", Tests' and all
| > packages since we've separated out the Core to a separate
| > configuration
| > - 'Core' includes the ConfigurationOfSeasideCore31
| > - 'Production' includes ConfigurationOfSeasideCore31 and "tools
| > recommended for production"...no 'Tests'
| > - 'Development' includes ConfigurationOfSeasideCore31 and
| > development
| > packages (excluding 'Seaside-HTML5','Seaside-Tools-Web', etc.),
| > includes
| > 'Tests'
| >
| > 10. ConfigurationOfSeaside31 would also include references to the
| > other Seaside31 configurations: ConfigurationOfComet31,
| > ConfigurationOfSeasideRest31. etc. Including them here would make
| > it convenient for someone to create a nice load expression that
| > includes everything they want for their project:
| >
| > (ConfigurationOfSeaside31 project version: #stable)
| > load: #('Production', 'Seaside-Zinc', 'Rest', 'JQuery',
| > 'Seaside-HTML5')
| >
| > 11. You are still including Kom as the default adaptor ... did you
| > want to switch to KomLite or Zinc as the default?
| >
| > 12. 'Comet-Core' 'Comet-Examples' 'Comet-Tests-Core' still included
| > in the baseline310: spec.
| >
| >
| > ------------ConfigurationOfGrease----------------------------------
| >
| > 1. Grease 1.1.0 is defined in the copy of Grease in the Seaside3.1
| > repository. There needs to be only one _master copy_ of the Grease
| > configuration and that's in the Seaside3.0 repository.
| >
| > 2. ConfigurationOfGrease and the packages will be shared between
| > Seaside3.0 and Seaside3.1.
| >
| > 3. It's not Grease if it has to be forked for Seaside3.1.
| >
| > 4. ConfigurationOfGrease does not validate correctly: #baseline110:
| > is specifying version '1.0.0-baseline' not '1.1.0-baseline'
| >
| > 5. there are additional validation errors after fixing number 4.
| >
| > 6. strip the class-side development support category (keep the
| > #validate method:).
| >
| >
| > ------------ConfigurationOfRss31----------------------------------
| >
| > 1. I now understand what you meant by "look for it in
| > ConfigurationOfSeaside31". Metacello works slightly differently
| > than you think. Here's the recast baseline spec:
| >
| > baseline310: spec
| > <version: '3.1.0-baseline'>
| > spec
| > for: #'common'
| > do: [
| > spec blessing: #'baseline'.
| > spec description: ''.
| > spec repository:
| > 'http://www.squeaksource.com/Seaside31'.
| > spec
| > project: 'Seaside-Core'
| > with: [
| > spec
| > className:
| > 'ConfigurationOfSeaside31';
| > versionString: #'bleedingEdge';
| > loads: #('Seaside-Canvas');
| > repository:
| > 'http://www.squeaksource.com/MetacelloRepository'
| > ];
| > project: 'Seaside-Canvas' copyFrom: 'Seaside-Core'
| > with: [ spec loads: #('Seaside-Canvas') ];
| > project: 'Seaside-Tests-Core' copyFrom:
| > 'Seaside-Core' with: [ spec loads:
| > #('Seaside-Tests-Core') ];
| > project: 'Seaside-Tools-Core' copyFrom:
| > 'Seaside-Core' with: [ spec loads:
| > #('Seaside-Tools-Core') ].
| > spec
| > package: 'RSS-Core' with: [ spec requires:
| > #('Seaside-Core' 'Seaside-Canvas') ];
| > package: 'RSS-Tests-Core' with: [ spec requires:
| > #('RSS-Core' 'Seaside-Tests-Core') ];
| > package: 'RSS-Examples' with: [ spec requires:
| > #('RSS-Core' 'Seaside-Tools-Core') ].
| > spec
| > group: 'Base' with: #('RSS-Core');
| > group: 'Base Tests' with: #('RSS-Tests-Core');
| > group: 'Base Examples' with: #('RSS-Examples') ]
| >
| > And the the version310: would looke like:
| >
| > version310: spec
| > <version: '3.1.0' imports: #('3.1.0-baseline')>
| > spec
| > for: #'common'
| > do: [
| > spec blessing: #'release'.
| > spec description: 'release 3.1.0 see
| > http://code.google.com/p/seaside/wiki/Seaside310Changelog'.
| > spec
| > project: 'Seaside-Core' with: '3.1.0';
| > project: 'Seaside-Canvas' with: '3.1.0';
| > project: 'Seaside-Tests-Core' with: '3.1.0';
| > project: 'Seaside-Tools-Core' with: '3.1.0'.
| > spec
| > package: 'RSS-Core' with: 'RSS-Core-pmm.68';
| > package: 'RSS-Examples' with: 'RSS-Examples-lr.26';
| > package: 'RSS-Tests-Core' with:
| > 'RSS-Tests-Core-lr.30' ]
| >
| > a similar technique can be applied to each of the other
| > configurations that reference ConfigurationOfSeaside31.
| >
| > 2. with the above modifications here's what will happen when you
| > load ConfigurationOfRss31:
| >
| > (ConfigurationOfRss31 project version: '3.1.0') record: 'Base'
| > a MetacelloNullRecordingMCSpecLoader(linear load :
| > linear load : 3.1.0 [ConfigurationOfRss31]
| > load : ConfigurationOfSeaside31
| > linear load : 3.1.0 [ConfigurationOfRss31]
| > load : ConfigurationOfSeaside31
| > linear load : 3.1.0 [ConfigurationOfRss31]
| > linear load : 3.1.0 [ConfigurationOfSeaside31]
| > load : ConfigurationOfGrease
| > linear load : 3.1.0 [ConfigurationOfSeaside31]
| > linear load : 1.1.0 [ConfigurationOfGrease]
| > load : Grease-Core-pmm.74
| > load : Grease-Pharo-Core-pmm.52
| > load : Grease-Pharo13-Core
| > load : Seaside-Core-pmm.773
| > load : Seaside-Pharo-Core-pmm.21
| > load : Seaside-Canvas-pmm.122
| > load : Seaside-Pharo-Canvas-pmm.4
| > linear load : 3.1.0 [ConfigurationOfSeaside31]
| > linear load : 1.1.0 [ConfigurationOfGrease]
| > load : Grease-Pharo13-Core
| > load : Grease-Tests-Core-pmm.84
| > load : RSS-Core-pmm.68)
| >
| > If one loads Rss31 as currently defined, you will not have a
| > "functional seaside" loaded as not even the 'Base' packages are
| > defined. This means that a developer will have to explicitly load
| > the 'Core'/'Base' group (depending upon which definition we end up
| > with) of Seaside31 to get a "functional seaside".
| >
| > UNLESS Seaside-Core and Seaside-Canvas CAN function as a standalone
| > unit, in which case the spec is "perfect"...
| >
| > 3. You will want to define a 'default' group for each of the
| > projects. For ConfigurationOfRss31, the 'default' group include
| > 'RSS-Core'
|
| Thanks, I'll work on it.
|
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| seaside-dev at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
More information about the seaside-dev
mailing list