SqueakMap tommorrow?

danielv at netvision.net.il danielv at netvision.net.il
Wed Sep 18 21:50:47 UTC 2002


goran.hultgren at bluefish.se wrote:
> 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)
Aha - good idea. Only installable packages in the quick d/l UI.

> package names (end perhaps we could even filter out based on Squeak
> version), then sure - that would be a nice to have start UI.
I'll implement a minimal UI along those lines or simpler (I can do some
morphic, but if I try to get tricky, I get ambitious, then lost, then
tired pretty quickly. So I'll KISS).

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

The minimal GUI will also be a downloadable package, so it can also be
updated later using itself.
 
> True. And being a customer - what is the next thing missing before we
> ship?

That's it, I said it -
1. Minimal UI. I'll do that - anything in particular I should know?
(that's it - as soon as this is usable, we release, because one the
first version of this is in the image, everything else can be d/led as a
package).
2. You create a silent update/publish interface (we'll have to agree on
some good simple semantics, see later).
3. I create a first, simple UI to use 2. Probably one using Avi's
ModuleFiler, and maybe a bit later one using simple ChangeSets. 
(Second release - a D/Lable package for trivial publish/update).

That's the seed. From here people CAN use it. Then the question will be
forever "what's the next most important feature" and I don't have an
opinion right now.

> I am aware that the feature list has a lot of icing but some things in
> there are somewhat important.
I agree completely - especially once a lot of people/packages are
already using SM.

> One thing is the mechanism for hiding/entering email addresses - since
> people don't want to get sucked up into Spammer dbs.

Umm, yes, people dislike that ;-)
 
> > > 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.
Agree. It is important to make an explicit and visible pointer to the
publish mechanism and more general documentation to anyone that uses the
download tool. You don't want it to be mysterious.

> > > 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.
I didn't understand that. Where is a category selected? where are there
references to categories?
 
> >  - 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?

Let me continue with short stories -
1. I get a clean image, look at the menu, download Connectors.
2. I develop an Outline editor, and want to publish it. I upload into
some ftp space.
3. I download the ChangeSetPackagePublisher, and use it to publish
OustEd (my editor ;-)
4. People see it, load it. For every package loaded, the system keeps
the name and timestamp for it (see next). Packages that are already
loaded aren't shown.
5. People find a bug. I fix bug and upload the fix. I want people to get
the new version. I update the SM entry. At a minimum, this simply
updates the timestamp on the entry, doing nothing else.
6. People get into the minimal UI again, see that my package is suddenly
back in their list, because the timestamp is newer. They reload, getting
bug fix.
 
> 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.
Yup.
 
> Well, ok. I assume you are referring to the "silent" API. Yes, true. But
> somewhere someone needs to ask the user for those Strings! :-)
I think an update interface should have all of the 3 above as optional
fields, and a mandatory timestamp (maybe computed at the server, to
prevent timezone trouble/cheating?).

Different UIs can get different amounts of information in different
ways.
 
> > 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.
That would be good for everyone that doesn't have ftp space. I have
plenty on my plate now though.

> 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?
Yup. One thing it did well IMO, is that it allowed people also to manage
their own local repository that isn't a clone, and can include private
stuff. It also had a good idea of version (versions are crypto-signed so
they're really immutable). The web-version had good interlinked
structure. It kept all versions of everything. It had many good ideas,
if you haven't given it a peek you should.

> Why (in your opinion) didn't it become a hit?
* It wasn't in the image, so it didn't help people d/l their stuff from
step 1.
* The install wasn't completely trivial - there was a wizard, instead of
the usual mere filein.
* It didn't help my clients (people d/ling the RB) to install it. I had
to write a script. Though having the dependencies declared allowed me to
generate it automatically, which is nice.
* It was a bit big - lots of code and ideas, some changes to the base
classes, so it was not quite trivial as possible to get into it.
* Closed package - because it managed the update process, it actively
got the code, limiting it to the methods of input and workflow supported
by the author, which was only picking files, at the time. No "update the
package for this changeset" menu item in the changesorter and such.
* I got annoyed with it after I saved the image with it open and it
killed my image. There was a fix for this, and HMM was helpful, but I
got tired.

> 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.
Cool.
 
 
> Do you think we should filter [inital UI] 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
I'll make something minimal and quick. As I said above, we can always
add, after we release, but we can never make it be sooner ;-) So that's
my first priority. I'll go start reading SqueakMap code now.

Stephan Rudlof <sr at evolgo.de> said:
> 1. Only show installable/Show all
> 2. Show only for current image version (2.9, 3.1, 3.2 etc)/Show for all
> versions/Show only for current image version or older
> 
> Now - how do we let the user do these choices? Preferences? (not necessarily
> easy to find) Checkbox items at the top of the menu?
Sounds good. We'll see what feels nice.

> 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.
Yup, that's great.

> 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).
You're right. We should have the SqueakFoundation url in the image from
release one.

> 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
:-) yup. Actually, IIUC, Vain-sencher is "wine-pourer" literally, or
simply bar-man.

> regards, Göran
> 

Daniel



More information about the Squeak-dev mailing list