Flags map to the SM concept of categories, widely used. The license, stability and so forth are categories. Categories are organized in trees. Some of the SM UIs allow you to browse through the tree.
Daniel
Andreas Raab andreas.raab@gmx.de wrote:
Hi Guys,
I'd like to raise a discussion about handling plugins that are managed at SqueakMap. As of this day, these will not be included by default with many VMs which is unfortunate as there are various packages for which it would make perfect sense to be included by default (RePlugin and Win32Fonts, for example). So the question is: How should we handle those? Would it be appropriate to add a separate flag to a package indicating that it contains a plugin which can be considered by a VM maintainer?! Are there any ways of querying SM packages for particular flags?!
Cheers,
- Andreas
Daniel Vainsencher danielv@netvision.net.il wrote:
Flags map to the SM concept of categories, widely used. The license, stability and so forth are categories. Categories are organized in trees. Some of the SM UIs allow you to browse through the tree.
Right. In short:
1. Each package (and in the future each package release too) belongs to 1-n categories. 2. The categories are structured in a tree (or a forrest as someone suggested at OOPSLA, he) and the tree is owned by the map. 3. If you know the password you can login using the web UI on the master and manipulate the category tree. Currently I am the only one knowing the password (or perhaps one or two of the guides) and the web UI is a bit... non pedagogic. But it works. 4. If a category is marked as "mandatory" one of its subcats *must* be chosen when registering/updating a package entry. License is one of those. Adding a mandatory category will cause this to be enforced when the registration is next updated. 5. I would *very much* like to have more feedback on the category tree. Almost noone have had any feedback to give me whatsoever actually.
Here is a snippet to check if the package named 'Balloon3D' has the category Squeak-L:
| map balloonIsSqueakL | map _ SMSqueakMap default. "A singleton" balloonIsSqueakL _ (map cardWithName: 'Balloon3D') categories includes: (map categoryWithId: '94277ca9-4d8f-4f0e-a0cb-57f4b48f1c8a'). "packages in SM1.0x are sometimes called 'cards'"
You can easily see all categories by exploring "SMSqueakMap default categories" or "SMSqueakMap default topCategories".
So Andreas - if you want some categories for this just post names and a oneline description. You can also include a URL for a category giving more information about it - we haven't used it much but here is an example (these should typically point into suitable descriptive pages on minnow I think), note the "More info" line at the top:
http://map2.squeakfoundation.org/sm/category/6407ed26-57a7-4742-8dad-d82 7618a9dbf
regards, Göran
Göran,
So Andreas - if you want some categories for this just post names and a oneline description.
How about this: "plugin" - this package is or contains a plugin to the Squeak VM which needs to be compiled for each platform individually.
[Note: this is just a proposal; if someone else has any better ideas I'd love to hear them].
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of goran.hultgren@bluefish.se Sent: Monday, March 10, 2003 10:09 AM To: The general-purpose Squeak developers list Subject: Re: [RFC][VM] Handling plugins in packages at SqueakMap
Daniel Vainsencher danielv@netvision.net.il wrote:
Flags map to the SM concept of categories, widely used. The license, stability and so forth are categories. Categories are organized in trees. Some of the SM UIs allow you to browse through the tree.
Right. In short:
- Each package (and in the future each package release too)
belongs to 1-n categories. 2. The categories are structured in a tree (or a forrest as someone suggested at OOPSLA, he) and the tree is owned by the map. 3. If you know the password you can login using the web UI on the master and manipulate the category tree. Currently I am the only one knowing the password (or perhaps one or two of the guides) and the web UI is a bit... non pedagogic. But it works. 4. If a category is marked as "mandatory" one of its subcats *must* be chosen when registering/updating a package entry. License is one of those. Adding a mandatory category will cause this to be enforced when the registration is next updated. 5. I would *very much* like to have more feedback on the category tree. Almost noone have had any feedback to give me whatsoever actually.
Here is a snippet to check if the package named 'Balloon3D' has the category Squeak-L:
| map balloonIsSqueakL | map _ SMSqueakMap default. "A singleton" balloonIsSqueakL _ (map cardWithName: 'Balloon3D') categories includes: (map categoryWithId: '94277ca9-4d8f-4f0e-a0cb-57f4b48f1c8a'). "packages in SM1.0x are sometimes called 'cards'"
You can easily see all categories by exploring "SMSqueakMap default categories" or "SMSqueakMap default topCategories".
So Andreas - if you want some categories for this just post names and a oneline description. You can also include a URL for a category giving more information about it - we haven't used it much but here is an example (these should typically point into suitable descriptive pages on minnow I think), note the "More info" line at the top:
http://map2.squeakfoundation.org/sm/category/6407ed26-57a7-4742-8dad-d82 7618a9dbf
regards, Göran
"Andreas Raab" andreas.raab@gmx.de wrote:
Göran,
So Andreas - if you want some categories for this just post names and a oneline description.
How about this: "plugin" - this package is or contains a plugin to the Squeak VM which needs to be compiled for each platform individually.
Would this be a subcategory of "Package type"? No, not if you also allow "contains" I guess. Ok, instead of guessing - which daddy do you think it should have? :-)
Perhaps we are talking about a new top category called "Package attributes" or something? Btw, that oneliner looks a tad long, but I can probably rephrase that a bit.
regards, Göran
How about this: "plugin" - this package is or contains a plugin to the Squeak VM which needs to be compiled for each platform individually.
Would this be a subcategory of "Package type"? No, not if you also allow "contains" I guess. Ok, instead of guessing - which daddy do you think it should have? :-)
Good question. I dunno (this is why I tagged this as [RFC]). One could go either way - simply flag a package as "containing" a plugin, or make up a separate package type for "being" a plugin. Both makes sense and I don't have a strong feeling either way.
Comments anyone?
Cheers, - Andreas
"Andreas Raab" andreas.raab@gmx.de wrote:
How about this: "plugin" - this package is or contains a plugin to the Squeak VM which needs to be compiled for each platform individually.
Would this be a subcategory of "Package type"? No, not if you also allow "contains" I guess. Ok, instead of guessing - which daddy do you think it should have? :-)
Good question. I dunno (this is why I tagged this as [RFC]). One could go
You don't know?! :-) Well, it happens to the best I guess. ;-)
either way - simply flag a package as "containing" a plugin, or make up a separate package type for "being" a plugin. Both makes sense and I don't have a strong feeling either way.
Comments anyone?
Well, adding a "Package type" called "Plugin" seems pretty reasonable. That would be "just" a clean plugin. Since they are fair targets for future dependencies many of them will probably end up as separate packages in the long run anyway.
We could also introduce a "misc" top category called "Package attributes" or something equally general and nondescriptive :-) in which we can place categories which we can't really find a good place for elsewhere.
If there are no more comments on this that can make me think otherwise then I will go for this solution. "Package type" is already mandatory but "Package attributes" can't be of course. So maintainers will just need to put that little "Contains plugin" category on their packages themselves.
Cheers,
- Andreas
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Daniel Vainsencher -
goran.hultgren＠bluefish.se