Re: A bit about SM1.1 and dependencies

[email protected] wrote:
> Well, given my plan of us being able to register "package
> configurations" associated with a package release *as* a Resource - it
> is needed. And Links too of course - Resources of course need to be
> linked to something
>
> But don't get scared by this - these two mechanisms are very simple and
> I have that stuff more or less implemented including package releases.
Not scared, and I don't doubt it's simple, just said it's not necessary.
You know, Simplest thing that could possibly work, You ain't gonna need
it, and all that crap... ;-)
 
> Things I *am* waiting with:
> - The ability to make modifications to the map in a distributed fashion.
> - And thus also: The API for modifying the map.
> 
> And two more things I *do* want to include:
> - A sensible cache instead of the braindead scheme right now. But this
> is also simple.
> - The new service architecture instead of the current "install or
> download" choice.
Distributed modification and cache are, IMO, easily delayed. We don't,
AFAICT, have a real performance/reliability problem that would make
these essential (though there might be other reasons for them I'm not
aware of...). OTOH, services and API for modifying would be really nice.
Services are important for making use of the dependencies, by letting
the category of the package indicate that it's a multiple, and modifing
would allow much convinience to developers.

On the gripping hand, the services architechture could actually also not
be part of the SM catalog - one might say it's an extension that can be
either used or ignored by the UIs, and that the only modification needed
to SM is to break off the existing install and such into such services.

> Note that the package configurations and corresponding dependency engine
> I have been blabbering about is *not* included here - that is meant to
> come as an addon later. And anyone could start coding that up right now
> I think.
I wouldn't know how because I don't know what the API for downloading a
specific package version will look like... but I might as soon as I do.

> Well, I am not sure what is the best way forward - I have SM1.1 on my
> drive and it does have package releases, quite a lot of refactoring
> done, links and resources in the model and the new service architecture
> halfbaked. I have a sketch in my head for a better cache model, need to
> whip through the web UIs so that we can register releases, resource etc
> - but that is pretty easy coding.
> 
> Anyway, I will try to throw in a bunch of hours in this the coming week
> - at least enough to post a developer snapshot so that anyone could help
> me - if there is interest. My current fixed price job is pressing me
> pretty hard. It will get easier in late feb, early march.
I have interest, and would be glad to help flesh out the services along
the lines above. Whether that'd be as a part of SM for you to integrate
or as a separate package - as you wish. It'll be very easy to specify
that the UIs require both SM and SM Services after we get dependencies,
so I don't see a problem... :-)

Daniel Vainsencher
From [email protected] Tue Feb 11 20:43:14 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 17780 invoked from network); 11 Feb 2003 20:43:13 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 11 Feb 2003 20:43:13 -0000
Received: from www-data by leia.bluefish.se with local (Exim 3.12 #1 (Debian))
	id 18ihFI-0003pM-00
	for <[email protected]>;
	Tue, 11 Feb 2003 21:43:12 +0100
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]A bit about SM1.1 and dependencies
Message-ID: <[email protected]>
Date: Tue, 11 Feb 2003 21:43:12 +0100 (CET)
From: =?ISO-8859-1?Q?G=F6ran_Hultgren?= <[email protected]>
References: <[email protected]>
In-Reply-To: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.6
X-Originating-IP: 212.105.10.110
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2003 20:43:14 -0000

Hi all!

Quoting Daniel Vainsencher <[email protected]>:
> [email protected] wrote:
> > Well, given my plan of us being able to register "package
> > configurations" associated with a package release *as* a Resource -
> it
> > is needed. And Links too of course - Resources of course need to be
> > linked to something
> >
> > But don't get scared by this - these two mechanisms are very simple
> and
> > I have that stuff more or less implemented including package
> releases.
> Not scared, and I don't doubt it's simple, just said it's not
> necessary.
> You know, Simplest thing that could possibly work, You ain't gonna need
> it, and all that crap... ;-)

Well, I am having a hard time seeing where we should record our dependencies if
we don't have Resources. They *are* needed. At least given my plan. :-)

> > Things I *am* waiting with:
> > - The ability to make modifications to the map in a distributed
> fashion.
> > - And thus also: The API for modifying the map.
> > 
> > And two more things I *do* want to include:
> > - A sensible cache instead of the braindead scheme right now. But
> this
> > is also simple.
> > - The new service architecture instead of the current "install or
> > download" choice.
> Distributed modification and cache are, IMO, easily delayed. We don't,

Sure. The cache thing is just something that annoys me - it is simply put
incredibly stupid right now.

> AFAICT, have a real performance/reliability problem that would make
> these essential (though there might be other reasons for them I'm not
> aware of...). OTOH, services and API for modifying would be really
> nice.
> Services are important for making use of the dependencies, by letting
> the category of the package indicate that it's a multiple, and modifing
> would allow much convinience to developers.

Yes, but the modifying API is coupled with managing distributed change. At least
as I have planned it. Otherwise the API would need to "call" the master server
using some for of RPC yadda, yadda...

> On the gripping hand, the services architechture could actually also
> not
> be part of the SM catalog - one might say it's an extension that can be
> either used or ignored by the UIs, and that the only modification
> needed
> to SM is to break off the existing install and such into such services.

Yes, probably.

> > Note that the package configurations and corresponding dependency
> engine
> > I have been blabbering about is *not* included here - that is meant
> to
> > come as an addon later. And anyone could start coding that up right
> now
> > I think.
> I wouldn't know how because I don't know what the API for downloading a
> specific package version will look like... but I might as soon as I do.

Well, true. :-)

> > Well, I am not sure what is the best way forward - I have SM1.1 on my
> > drive and it does have package releases, quite a lot of refactoring
> > done, links and resources in the model and the new service
> architecture
> > halfbaked. I have a sketch in my head for a better cache model, need
> to
> > whip through the web UIs so that we can register releases, resource
> etc
> > - but that is pretty easy coding.
> > 
> > Anyway, I will try to throw in a bunch of hours in this the coming
> week
> > - at least enough to post a developer snapshot so that anyone could
> help
> > me - if there is interest. My current fixed price job is pressing me
> > pretty hard. It will get easier in late feb, early march.
> I have interest, and would be glad to help flesh out the services along
> the lines above. Whether that'd be as a part of SM for you to integrate
> or as a separate package - as you wish. It'll be very easy to specify
> that the UIs require both SM and SM Services after we get dependencies,
> so I don't see a problem... :-)

I will try to get it out this weekend and perhaps you could take over the
services part.

regards, Göran

Göran Hultgren, [email protected]
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek
From [email protected] Wed Feb 12 00:04:23 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 29185 invoked from network); 12 Feb 2003 00:04:22 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 12 Feb 2003 00:04:22 -0000
Received: from [80.178.100.204] ([80.178.100.204]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Wed,
 12 Feb 2003 02:04:22 +0200 (IST)
Date: Wed, 12 Feb 2003 01:55:23 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]A bit about SM1.1 and dependencies
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2003 00:04:24 -0000


[I claim resources/links not needed for depedencies]
=?ISO-8859-1?Q?G=F6ran_Hultgren?= <[email protected]> wrote:
> Well, I am having a hard time seeing where we should record our dependencies if
> we don't have Resources. They *are* needed. At least given my plan. :-)

Ok, just to show what I mean. Suppose I make a package type that holds a
single method that goes something like
^#((RBModel 1.09)
(RBGUI 1.06)
(RBTests 1.05))

Then I write a service that loads this kind of package, and does
packagesList collect: [:packagePair | SMSqueakMap loadPackage:
packagePair first version: packagePair second].

Or maybe something a little more complicated, but you can see where I'm
going... I don't need much more support.

> Sure. The cache thing is just something that annoys me - it is simply put
> incredibly stupid right now.
Hey, I'm just one voice here.. and not even offering any cash, so... ;-)

> Yes, but the modifying API is coupled with managing distributed change. At least
> as I have planned it. Otherwise the API would need to "call" the master server
> using some for of RPC yadda, yadda...
Ah, I see what you mean. I'd thought you were going to implement that
RPC anyway, since the image do need to communicate anyhow. 

> > I have interest, and would be glad to help flesh out the services along
> > the lines above. Whether that'd be as a part of SM for you to integrate
> > or as a separate package - as you wish. It'll be very easy to specify
> > that the UIs require both SM and SM Services after we get dependencies,
> > so I don't see a problem... :-)
> 
> I will try to get it out this weekend and perhaps you could take over the
> services part.

Cool.

Daniel
From [email protected] Wed Feb 12 12:05:34 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 19336 invoked from network); 12 Feb 2003 12:05:34 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 12 Feb 2003 12:05:34 -0000
Received: from [213.80.63.110] (helo=aSqueakSystem)
	by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian))
	id 18ivdt-0004Ia-00
	for <[email protected]>;
	Wed, 12 Feb 2003 13:05:33 +0100
X-Mailer: Celeste 2.0.4917
Date: Wed, 12 Feb 2003 13:05:22 +0100 
In-reply-to: <[email protected]>
Subject: Re: [Squeakfoundation]A bit about SM1.1 and dependencies
To: Discussing the Squeak Foundation
	<[email protected]>
References: <[email protected]>
From: [email protected]
Message-Id: <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2003 12:05:34 -0000

Hi!

Daniel Vainsencher <[email protected]> wrote:
> [I claim resources/links not needed for depedencies]
> =?ISO-8859-1?Q?G=F6ran_Hultgren?= <[email protected]> wrote:
> > Well, I am having a hard time seeing where we should record our dependencies if
> > we don't have Resources. They *are* needed. At least given my plan. :-)
> 
> Ok, just to show what I mean. Suppose I make a package type that holds a
> single method that goes something like
> ^#((RBModel 1.09)
> (RBGUI 1.06)
> (RBTests 1.05))
> 
> Then I write a service that loads this kind of package, and does
> packagesList collect: [:packagePair | SMSqueakMap loadPackage:
> packagePair first version: packagePair second].
> 
> Or maybe something a little more complicated, but you can see where I'm
> going... I don't need much more support.

Ok, this looks to me like "virtual packages". A package that has no
content and loads specific versions of other packages. In fact - this is
a "static load script" given my previous terminology. (Static in the
sense that it will always result in the same package releases being
loaded)

But this plan doesn't AFAICT make it possible to have multiple possible
configurations for RB. I assume that the virtual package/load script you
described above would be "RB".

It would also mean that you need to make a new version of RB if you want
to change the dependencies for RB - so you get "cascading version
changes" - package Y is released in a new version and X depend on it so
must also be released in a new version etc. etc.

[SNIP]
> Ah, I see what you mean. I'd thought you were going to implement that
> RPC anyway, since the image do need to communicate anyhow. 

No, I have a greater plan lined up. :-) But we can talk about that
later.

> > > I have interest, and would be glad to help flesh out the services along
> > > the lines above. Whether that'd be as a part of SM for you to integrate
> > > or as a separate package - as you wish. It'll be very easy to specify
> > > that the UIs require both SM and SM Services after we get dependencies,
> > > so I don't see a problem... :-)
> > 
> > I will try to get it out this weekend and perhaps you could take over the
> > services part.
> 
> Cool.

Perfect. I will then aim for getting what I have got to you with some
explanation on what I was aiming for in the "services area" - but you
can of course ignore that and do what you like - just as long as it is
better than what we have now!

regards, Göran