Hmm, I think it's clear we're not all on the same page here, and I think we better address this sooner rather than later.
This is my proposed base policy on what should go into the image * Has to help all Squeakers. Being cool (Connectors) doesn't cut it - that can live on SM. TestRunner ENHs encourage more SUnit tests, so they might go in. * It has to be stable. There is no reason now to integrate unstable code. Young code can live on SM until it's tested. If package maintainers prefer it to what's in the image, let them depend on it. This has two benefits - - Acceptance in the community is not binary - you can have users, even many, before the code is in the image. - The use and testing will make the code stable, at which point, we can put it in the image. * It has to be understandable. Add class comments, reduce class count/size, reduce functionality to the minimum that really needs to be in the image. Just keep it simple.
If we let things in the image that make it bloated, or unstable, or even stable but unmaintainable, we're eating the goose. I think if we're commited to making Squeak viable in the long term, we need to keep these things as high priorities.
At the same time, to help people that contribute work to squeak to know where to aim, I think we must make the criteria clear, whether we agree they are similar to the above or not. I reviewed the Mission Statement now, and it doesn't say much about it, which I think is a bug.
I'd like comments on this at least from all Guides.
Before we decide how to get there on any specific package, we need to make it clear where we're going.
Daniel
Andreas.Raab@gmx.de wrote:
Hi Guys,
I'm not qualified to answer about the benefits of the new primitive interfaces, I'm quite ignorant in these things. John M has (IIUC) spoken in favor of it. Could we get some more input from the experts?
From what I can see looking over the primitives, there are two things missing. One is support for socket options and one support for security stuff in file access. Both are not hard to add but can be painful if missing.
That said, two extra thoughts. For one thing, it'd be nice to have a version that doesn't put 82 classes into "reorganize me" - makes it really hard to grok this stuff for someone who has no idea how to reorganize flow ;-)
Secondly, I am scared to death about the issue of backward compatibility. I urge you to consider leaving the current streams and sockets basically intact and rather have flow be an _alternative_ to instead of a _replacement_ of the current classes. From what I can see there are only very few places affected where global names collide and if that's the entire problem someone ought to be able to come up with a few alternative names. With the current version of flow you will instantly break any code that - for example - uses "FileStream readOnlyFileNamed: 'foo.bar'" or "Socket newTCP" (and believe me, there are plenty of those in Croquet and if you need another instructive example just try to install flow two times ;-) I can understand that providing a full compatibility layer in flow may be neither doable nor desirable but that's only another argument for leaving the current classes intact to the point that there is at least a chance of running existing code. The entire situation here strikes me of being amazingly similar to the backward compatibility issues with modules - in both cases fundamental notions are being replaced instead of augmented. Let's try hard not to repeat this debacle.
Cheers,
- Andreas
(This is a draft I think we should post to the squeak-dev to generate the main discussion there. If you guys have comments/additional issues to raise...)
As I noted before, a few people have requested that the Flow work by Craig be integrated into the base image.
This work:
- Replaces the primitive interface to sockets and other External
Resources
- Refactors the stream hierarchy
I've had a few concerns that the changes might create too much change all at once, considering that many things use the stream hierarchy. After speaking to Craig about these issue, it seems that (Craig, please correct me if I'm wrong here)-
- The new streams implement all the old protocols, so that the main
compatibility problem should be direct references to the old class names. This is easy to fix incrementally for packages, and fairly quickly for the image itself. 2. The package as it is now can coexist with the existing libraries, making testing quite feasible at low risk.
So I guess this move should be pretty easy. Open questions -
Should we do it?
How do we test to minimize risk?
When?
Do or not?
If people know of any general objections/problems with this code, it's best to put them in the open now.
I'm not qualified to answer about the benefits of the new primitive interfaces, I'm quite ignorant in these things. John M has (IIUC) spoken in favor of it. Could we get some more input from the experts?
About the stream refactorings, I think several people have used Flow to develop their own applications. Luciano has mentioned that he's used it for several and liked it. More evaluations would be useful here.
- Testing
As to format, Craig has agreed to post these changes on SM in the precise form he'd prefer to issue the proposed updates. As to how to make sure it doesn't cause problems for this or that package or application - that's up to you guys out there that use your sockets for more than reading mail... ideas?
- When?
Probably not in 3.4 (just to keep the release finite and near), but possibly in 3.5. This depends on Craig posting on SM in the proposed format, and mostly on when we get enough testing input.
Daniel _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
-- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
- It has to be understandable. Add class comments, reduce class
count/size, reduce functionality to the minimum that really needs to be in the image. Just keep it simple.
I agree with this, certainly. For example, Flow should not go in the image - because _no_ network stuff should be in the image ab initio. Yes, I know we need some network stuff to allow practical use of SM etc, but _the base image_ should have none of this.
There is, however, a very good argument for building and providing a 'typical' image with all the usual development tools preinstalled and probably for a newbie/demo image with lots of pleasing tchotchkes and explicatory stuff.
tim
Tim Rowledge tim@sumeru.stanford.edu wrote:
- It has to be understandable. Add class comments, reduce class
count/size, reduce functionality to the minimum that really needs to be in the image. Just keep it simple.
I agree with this, certainly. For example, Flow should not go in the image - because _no_ network stuff should be in the image ab initio. Yes, I know we need some network stuff to allow practical use of SM etc, but _the base image_ should have none of this.
Exactly.
There is, however, a very good argument for building and providing a 'typical' image with all the usual development tools preinstalled and probably for a newbie/demo image with lots of pleasing tchotchkes and explicatory stuff.
Yes. And we can do this already (to some extent) by simply registering a "load script" package on SM that builds such a "distro" image by installing packages using SM.
And we can actually also start considering premade images as "packages" - I haven't fully thought it through, but it would enable some good things. Like to be able to depend on specific kernel images. And of course a nice place to download images from!
regards, Göran
This is my proposed base policy on what should go into the image...
That all sounds reasonable. If we want to make policy, I think I would (somewhat loosely) state it as simply "the released image should contain things for which omission would cause confusion or inconvenience to a new user". Note that, as our distribution technology changes (and we get things like utterly-minimal images, pervasive network installation, unloading, etc.), the implications of that statement will evolve.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
Daniel Vainsencher danielv@netvision.net.il wrote:
Hmm, I think it's clear we're not all on the same page here, and I think we better address this sooner rather than later.
This is my proposed base policy on what should go into the image
- Has to help all Squeakers. Being cool (Connectors) doesn't cut it -
that can live on SM. TestRunner ENHs encourage more SUnit tests, so they might go in.
- It has to be stable. There is no reason now to integrate unstable
code. Young code can live on SM until it's tested. If package maintainers prefer it to what's in the image, let them depend on it. This has two benefits -
- Acceptance in the community is not binary - you can have users, even
many, before the code is in the image.
- The use and testing will make the code stable, at which point, we can
put it in the image.
- It has to be understandable. Add class comments, reduce class
count/size, reduce functionality to the minimum that really needs to be in the image. Just keep it simple.
If we let things in the image that make it bloated, or unstable, or even stable but unmaintainable, we're eating the goose. I think if we're commited to making Squeak viable in the long term, we need to keep these things as high priorities.
Daniel, I agree with everything you say BUT on the other hand I *strongly* disagree! ;-)
My point being that new stuff should simple NOT go into the image *at all*! It seems to me that you are perhaps forgetting the base principle that only fixes+really good enhs+package removals should go into the base image! It is easy to forget though - we all tend to do that in these discussions.
For example, TestRunner... Why is that in the image? Cut it out into a package.
So please, stop thinking in terms of "the base image"! Flow? It should IMHO not go into the base image. In fact IMHO Networking should rather be *cut out* of the image into a package. Much like Tim said in another reply.
I also agree with Michael's idea to split the low layer from the high layer (Sockets vs Streams typically).
(Anyway, perhaps I misunderstood Daniel here - AFAIK we are all in agreement on this, I just didn't think it sounded like that in this particular email. ;-) )
At the same time, to help people that contribute work to squeak to know where to aim, I think we must make the criteria clear, whether we agree they are similar to the above or not. I reviewed the Mission Statement now, and it doesn't say much about it, which I think is a bug.
We can always make addendums! :-)
I'd like comments on this at least from all Guides.
Before we decide how to get there on any specific package, we need to make it clear where we're going.
I strongly urge everyone to keep the focus on *packages* and not the base image. This also applies to the discussion about 3.4alpha going into beta and the discussion about putting SM into the base image, btw.
If people still want to talk about a "base" of some kind then by all means we should create one! How? By selecting packages that we want to consider to be the base packages.
regards, Göran
goran.hultgren@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
This is my proposed base policy on what should go into the image
... So please, stop thinking in terms of "the base image"! Flow? It should IMHO not go into the base image. In fact IMHO Networking should rather be *cut out* of the image into a package. Much like Tim said in another reply.
... I strongly urge everyone to keep the focus on *packages* and not the base image. This also applies to the discussion about 3.4alpha going into beta and the discussion about putting SM into the base image, btw.
If people still want to talk about a "base" of some kind then by all means we should create one! How? By selecting packages that we want to consider to be the base packages.
I was just thinking that perhaps we need a term for what we've been calling the "base image", even though it will eventually be composed of packages. (I think Daniel was probably referring to this new thing, not the old image.)
Should it be called the "base release"? Or perhaps the "base configuration"? (I guess that one would have to wait until we have support for package configurations.)
We still want to have this concept of a "base release", which will be the thing that we release as Squeak 3.4, 3.5, 4.0, etc., even though it will be composed of packages. Of course, this release won't necessarily be the totally dominant form of Squeak that has been used by everyone in the past... other people/organizations may come up with competing releases/configurations, too, since it will now be much easier to do so.
But there will still be some value in having our group (The Guides) put out a release on a regular basis, as a sort of standard... the thing that will appear on squeak.org for people to download.
So what should we call this thing? :-)
And we have talked about a minimal release versus a larger "kitchen-sink" release (similar in content to the current base image)... I guess we will have to come up with names for both.
- Doug
Doug Way dway@riskmetrics.com wrote:
goran.hultgren@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
This is my proposed base policy on what should go into the image
... So please, stop thinking in terms of "the base image"! Flow? It should IMHO not go into the base image. In fact IMHO Networking should rather be *cut out* of the image into a package. Much like Tim said in another reply.
... I strongly urge everyone to keep the focus on *packages* and not the base image. This also applies to the discussion about 3.4alpha going into beta and the discussion about putting SM into the base image, btw.
If people still want to talk about a "base" of some kind then by all means we should create one! How? By selecting packages that we want to consider to be the base packages.
I was just thinking that perhaps we need a term for what we've been calling the "base image", even though it will eventually be composed of packages. (I think Daniel was probably referring to this new thing, not the old image.)
Ah, ok. :-) Didn't get that.
Should it be called the "base release"? Or perhaps the "base configuration"? (I guess that one would have to wait until we have support for package configurations.)
Actually we can already today do what I call "load scripts". Perhaps I need to publish one to show how it is done. It is essentially a .st.gz file that uses the SqueakMap API to install packages. Yes, we don't have SMPackageRelease yet - but you can either install "the latest known".
When we get SMPackageRelease then we will be able to make these "load scripts". They can be used to build images and thus can be considered to be "distros" or whatever. Again - this is STTCPW and even thought they are not declarative they can instead do "smart things" like asking the user what he/she wants! In that case it should be called a "dynamic load script" (see category "Package type") since it doesn't necessarily produce the exact same result each time. The other is "static load script".
Sidenote:
I am leaning over to Daniels general design idea that if SM has "packages" in a more general sense (and package releases) then we can handle what Daniel and I have been calling "configurations" as simply another kind of package. Now - my last design in my head lets SM handle three basic things: SMPackage (with SMPackageRelease), SMResource and SMPerson.
In such a future SM a package would be typically installable code and SMResource would catch much everything else. The line is a bit blurry for some things, but the main difference is that SMPackage has releases (versions) and SMResource doesn't.
Blabla, I will type all this down this today... :-)
We still want to have this concept of a "base release", which will be the thing that we release as Squeak 3.4, 3.5, 4.0, etc., even though it will be composed of packages. Of course, this release won't necessarily be the totally dominant form of Squeak that has been used by everyone in the past... other people/organizations may come up with competing releases/configurations, too, since it will now be much easier to do so.
Right. The technical name for such a distro on SM would probably be a "load script". At least until we have more advanced concepts of creating coherent package configurations - I am actually not building that into SM - the idea being that hey, it's just a new kind of resource/package which you can put up there. (I know my thoughts are hard to follow)
But there will still be some value in having our group (The Guides) put out a release on a regular basis, as a sort of standard... the thing that will appear on squeak.org for people to download.
Exactly.
So what should we call this thing? :-)
Well. :-) Technically one way of doing this would IMHO (and for starters) consist of:
1. A kernel image. (I am thinking of posting these as an SMResource on SM) 2. A load script. (Since a load script is a package it can actually have releases)
So... being concrete, we create a kernel image - in the beginning that is essentially what we already have. We name it something and put it on SM as an SMResource named for example: "Guide kernel image 3.5". Note that version is included in name since a resource doesn't have releases.
Then we post a package of "Package type" "Static load script" (or dynamic, I don't know). That package is a simple .st.gz file that uses the SqueakMap API to install specific package releases in a specific order. It could even do tricks along the way since it is after all a script - that is a good flexibility to have I think. We name the package "Guide distribution build script" (or something) and set the version of the specific package release to (to keep in synch) "3.5". Something like that.
We could also post a "prebuilt" image like a resource named "Guide distribution prebuilt image 3.5".
And if you want to build it yourself you simply download the "Guide kernel image 3.5", fire it up, install version 3.5 of package "Guide distribution bild script" and off it goes loading all the other packages on top.
Ok, so given all this. Names like "distribution" or "build script" pops up. Perhaps there are other names for the "distribution" thing. The name "load script" or "build script" does on the other hand sound like exactly what they are so they are pretty good IMHO.
And we have talked about a minimal release versus a larger "kitchen-sink" release (similar in content to the current base image)... I guess we will have to come up with names for both.
- Doug
Well, see above.
regards, Göran
On Tuesday, November 26, 2002, at 04:07 AM, goran.hultgren@bluefish.se wrote:
Doug Way dway@riskmetrics.com wrote: ...
We still want to have this concept of a "base release", which will be the thing that we release as Squeak 3.4, 3.5, 4.0, etc., even though it will be composed of packages. Of course, this release won't necessarily be the totally dominant form of Squeak that has been used by everyone in the past... other people/organizations may come up with competing releases/configurations, too, since it will now be much easier to do so.
Right. The technical name for such a distro on SM would probably be a "load script". At least until we have more advanced concepts of creating coherent package configurations - I am actually not building that into SM - the idea being that hey, it's just a new kind of resource/package which you can put up there. (I know my thoughts are hard to follow)
The load script concept sounds good as you describe it... a good way to do things until perhaps true package configurations are available.
Yes, the technical name for that can be "load script". I was mostly just trying to think of what end-user-friendly name we should give to the stuff that used to be in the "base image"... "load script" doesn't sound like a great name in that sense. Perhaps we could just call it the "base distribution" or "base release" or something like that.
(Even though this "distribution" would really consist of a kernel image plus a load script.)
We could also post a "prebuilt" image like a resource named "Guide distribution prebuilt image 3.5".
And if you want to build it yourself you simply download the "Guide kernel image 3.5", fire it up, install version 3.5 of package "Guide distribution bild script" and off it goes loading all the other packages on top.
That might be good. Perhaps "Guide distribution" would be more specific than "base distribution". Either sounds reasonable.
Ok, so given all this. Names like "distribution" or "build script" pops up. Perhaps there are other names for the "distribution" thing. The name "load script" or "build script" does on the other hand sound like exactly what they are so they are pretty good IMHO.
Yes.
- Doug
squeakfoundation@lists.squeakfoundation.org
-
Craig Latta -
Daniel Vainsencher -
Doug Way -
goran.hultgren＠bluefish.se -
Tim Rowledge