SqueakMap tommorrow?

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Wed Sep 18 09:03:41 UTC 2002


Hi Daniel and all!

danielv at netvision.net.il wrote:
> 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.

Well, the UI is very separated from the domain model. So if you can whip
up a complemental minimal UI that for example is simply a two-level deep
menu (with letter intervals on the first level, like the good old "new
morph" menu) of *installable* (downloadurl endswith .cs, .cs.gz, .st)
package names (end perhaps we could even filter out based on Squeak
version), then sure - that would be a nice to have start UI.

And the SMSqueakMapBrowser could then be installed by using that of
course.

> > > 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.

True. And being a customer - what is the next thing missing before we
ship?

> [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 ;-)

No, this is not nagging - it's constructive. I am delighted someone sees
the big advantage of having SqueakMap.
I am aware that the feature list has a lot of icing but some things in
there are somewhat important.
One thing is the mechanism for hiding/entering email addresses - since
people don't want to get sucked up into Spammer dbs.

> > I will take a look at Avi's code and begin to think about add/updating package
> > entries from within the SMSqueakMapBrowser.
> Great!

Do you think adding/updating entries from within the browser to be one
of the "big" missing pieces?
Personally I am not sure - it doesn't happen very often so I thought
that the current requirement of doing it through the web wasn't too
harsh.

> > :-) 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.

Just tell me what you want to do - this is a work for/of the community -
not my personal toy.

> > 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. 

Yes, the only current "problem" when updating is the possibility that
the slave map is out of synch and that you select categories that have
been removed. A very unlikely situation, and perhaps we could even let
it pass by making the server "cope" with it. A reference to a missing
category could be resolved to a category called "Missing category" or
something.

>  - 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.

Ok... what do you mean? What is an update notification?

>  - 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".

Yes, when I (or someone brave) have implemented the "update entry" in a
morphic UI we should of course have a nice message that people can send
to bring that UI up even though there is no SMSqueakMapBrowser around.

When doing a new release of a package there are probably only three
fields that need updating:
1. Version name
2. Version comment
3. Download url (but not necessarily if you have a "current" softlink or
something that doesn't change)

So we should of course also implement a message that is "silent" and
just wants those three Strings (or all) so that other tools easily can
update the SqueakMap entries.

> > 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.

Well, ok. I assume you are referring to the "silent" API. Yes, true. But
somewhere someone needs to ask the user for those Strings! :-)

> 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 :-)

I agree. Perhaps the best way (as you have outlined) to attack this is
to let the tools call SqueakMap instead of the other way around.
Pretty obvious when you think about it - SqueakMap is just one guy, the
others are many... :-)

> 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).

Perhaps someone could fix that? I am all for diversity when it comes to
package/code storage.
But not when it comes to catalogs like SqueakMap! We only want ONE of
those. But with very good integration possibilities.
Btw, is anyone using SCAN? I seem to recall you did for the RB, right?
Why (in your opinion) didn't it become a hit?

> 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? :-)

Yes. After reading this message I am focused on adding the "add entry"
and "update entry" from within Squeak.
I will start by implementing it silently (the API for all the other guys
to use) and then we can add a UI on top.

What I would like Daniel to do (if I may be so bold to ask!)
concurrently is to implement the
two-level-minimal-UI-menu-for-installing-installable-packages discussed
above and finding a place in the 3.2 image to hook it in.

Do you think we should filter it by:

1. isInstallable - currently that means .cs or .cs.gz, should add .st,
.st.gz and eventually .zip according to Ned)
2. isCompatbile - currently we can check for the mandatory categoru
called "Squeak versions":
> http://marvin.bluefish.se:8000/sm/category/df573711-4924-4af7-a6e6-2ccaf8b1d2d6

Should we add a field (optional) for each package telling the minimal
update level for it to work? If it is entered in the package and the
client image is below that threshold we can throw up a simple warning to
the user to go ahead on his/her own risk.

If you implement such a menu (given an API from me of course to get
those package names) then we can whip up a minimal .cs to throw into the
3.2 update stream. Scott Wallace seems to think it would be worthwhile.
But before we do that we really need to deploy a "real" master. I can
ask Cees for an account on squeafoundation.org to do that (or if he does
it himself).

What we need to realize is that from that point on the development of
SqueakMap will become harder because we will have to deal with "old
data". But I have realized that the approach I have taken with the
logfile etc makes it quite easy to evolve. If you make major changes you
simply issue a reloadLog to the map and it will sortof "migrate itself".
:-)

> 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.

Ok, you have me convinced. Then you will just have to prove to me that
someone will use those hooks, right? :-)
Because now they are on the top of my list.

> Daniel Vainsencher

regards, Göran

PS. A funny thing - I have always read your name as "Vainsacher" (for no
apparent good reason whatsoever) and just the other day I  realized I
have been reading it completely wrong. I don't normally do things like
that. Isn't the brain a weird sometimes? DS



More information about the Squeak-dev mailing list