Hi doru I will spend amos time to do an analysis of the possible paths. Right now RPackage Organizer is fill up based on PackageOrganizer so a category is mapped to a package and extensions are managed well (probably some funky case still do not work 100%). Now what marcus and igor were afraid is that big packages with a lot of subcategories would become a lot of packages. Examples: Morphic -> Morphic-Menu, Morphic-Basic, Morphicâ¦. To me this is not a problem but I introduced at the level of packages the possibility to tag classes: This way we could take MCWorkingCopies as package (but with the fucking matching that nobody understand really) and the large packages could be displayed in browser Package Morphic Morphic-menu classes Morphic-Basic classes ⦠Now I do not like that because it means that we will have to do all the matching i.e. *Morphic-Menu methods belong to Morphic because there is Morphic and not Morphic-Menu as packages.
B.
Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following:
Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.
yes we have already that. Probably with some bugs with the matching in edge cases.
Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations.
Yes this is what afraid marcus and igor because people will cry that they have to change the configurations and that they will lose the subcategory. For me I want to get rid of categories this is a bogus concept #cat #Cat 'Cat' 'cat' string bad management and pattern matching as well as the monolithic systemOrganizer is terrible.
Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories.
So, why should this not work?
Cries: "oh my nice package now is split in multiple onesâ¦.. kind of problems"
Btw, there is a working basic GlamorousClassicCoder using RPackage. I did not announce it yet because there are still details to deal with.
Nautilus is fully working on RPackage too. :) So I will continue to see what I can do. To me I would simplify everything. We have too many concepts. I would love to remove category and have packages. We have a good implementation of packages.
Cheers, Doru
On 28 Oct 2011, at 13:20, Stéphane Ducasse wrote:
Hi guys
so what do we do with RPackage - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. but this means that we will stay with the old browsers. Sounds like a promising future. - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose a real plan to get towards a solution.
Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. Because we have categories in addition⦠I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this means that we will have to match the complete system with subcategories ( Graphics-Core should match Graphics*
So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete discussions. Apparently nobody care anyway. So this should not be important after all.
Stef
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."