goran.hultgren@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... ;-)
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
Hi all!
Quoting Daniel Vainsencher danielv@netvision.net.il:
goran.hultgren@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@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
squeakfoundation@lists.squeakfoundation.org