Replies to choice bits:


=?ISO-8859-1?Q?G=F6ran_Hultgren?= <goran.hultgren at bluefish.se> wrote:
> Hmmm. Perhaps. Or simply stuff SMSqueakMapBrowser in there, it's not that
> complicated is it? :-)
It isn't quite minimal, but I really don't care - as long as we get
something into the image.
 
> > But however simple it is, it doesn't really help people if it's not in
> > the image. Consider the state we're in after both scenarios I described
> 
> I agree. I have simply not lobbied that hard since it is still "beta".
> It is shaping up pretty good though.
True, but you still want to work in small iterations, and do the most
important scenarios first. I think 'enough to ship' is really close,
even if there'll be more iterations later.

[feature list...]
Luxuries. Just consider how many package are not being used every day
because the isn't simlpe access to a simple list, from the base image.
Everything after the list, download button, and publish mechanism is
just icing and will make a much smaller difference. There, I got it off
my chest, I'm not nagging any more ;-)
 
> I will take a look at Avi's code and begin to think about add/updating package
> entries from within the SMSqueakMapBrowser.
Great!
> :-) Well, you have all the code... Kidding aside, I think the add/update will
> work approximately like this:
[snip]
I'd be delighted to cooperate on this, but I definitely wouldn't pick up
and take it somewhere you don't want to go yourself.

> I will add adding/updating package entries in SMSqueakMapBrowser but I am not
> sure how I should hook up some form of "publish" mechanism and still keep
> SqueakMap neutral in that particular "war"...
> 
> Any ideas?

Yes - make the minimal update mechanism. 
 - You don't have to control conflicts, we can start by assuming only
one person maintains the entry, so there are none conflicts. 
 - SqueakMap isn't the repository, so you can't control the update of
the source itself. OTOH, this lets you relax about allowing an update
notification (that doesn't change significant details). Authorization
might not even be needed at all for this.
 - You don't have to provide a GUI, nor support specific formats - just
create an interface to let SqueakMap be updated by external tools. I'm
perfectly happy to add a couple of quick interfaces like "mail changeset
to list and update SqueakMap" and "upload logical module to ftp and
update SqueakMap", and someone else can write "upload XML SIF file in
freenet distributed repository encoded in spoofed DNA data".


> Well, something like that. It's not that hard to implement actually. I would
> guess the most work will be in the morphic UI...
Only if you want it, see above.

BTW, ModuleFiler by itself is simply a way to generate standard fileouts
(so it's not a format/repository position at all). The important thing
it does, is that it happens to know how to file out such subsets of code
that can model modules perfectly (a category + some class extensions). 

So these should be a particularly useful sort of thing for people to
update, not that the meta-data map has to care :-)

BTW, I just noticed that if http://swiki.gsug.org:8080/sqfixes/ only
used a fixed url for the current version of a specific package, that
would be a format that's already supported as an automaticly updated
repository (though it's only for small stuff).
 

Avi said:
> It might also be interesting to think about how DVS and SqueakMap could be
> integrated, so that you could cleanly upgrade to a new version of a
> package you already had loaded.  And of course getting sqcvs involved as
> well would be nice...
Can we keep the first version minimal? please? :-)

Goran:
> I think I will let this issue rest a while and we can get back to it when
> adding/updating package entries work from within the SMSqueakMapBrowser, ok?
IMHO, people will want to update their package from their development
tool, not from a special GUI that wants NOT to know how they work. So I
think an interface dev tools can hook into is more important than making
it work from SMSMB.

Daniel Vainsencher