[Squeakfoundation]A bit about SM1.1 and dependencies

[Göran Hultgren]

Hi all!

Quoting Daniel Vainsencher <danielv at netvision.net.il>:
> goran.hultgren at bluefish.se 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, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek