On 11/12/2009 07:29 PM, Ludovic Dubost wrote: > > Any other opinion about the name: > > "Extension Repository" has 1 vote
+1 Happy hacking, Anca > > ? > > Jerome Velociter a écrit : >> Hello, >> >> On 10/23/09 11:19 PM, Ludovic Dubost wrote: >> >>> Hi, >>> >>> I started working on a proposal to redesign code.xwiki.org >>> >>> http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiExtensionRepositoryRedesign >>> >>> >>> Please comment and/or modify this document. >>> >>> The main thing would be to agree that there should be one "unique" >>> repository for anything related to XWiki. >>> >>> If we agree on that, I would like to start a vote for the name. The >>> name could be I think any combination of a "prefix" or "suffix" or a >>> magical unrelated name. >>> >>> * Possible Prefix >>> o Add-On >>> o Extension >>> o App >>> o Store >>> o Modules >>> o Plugins >>> >> >> I like "Extension" as prefix, and I'll vote for it. I've always thought >> the use of "extension" we are currently doing on code.xwiki.org is wrong >> (as in "An extension is an application or script that integrates or >> interacts with XWiki. In other word it's anything that doesn't fit in >> any other category ;)"). Extension captures well the polymorphism of >> what the repository will propose. And well, XWiki is all eXtensibility, >> isn't it? >> >>> * Possible Suffix >>> o Directory >>> o Repository >>> o Store >>> o Catalog >>> >> >> Here I like for "repository", as this is what ultimately we target for >> code.xwiki.org (similar to a "maven" repository for XWiki extensions, >> that can be used by the future extension manager >> http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager). "Store" is >> maybe a more trendy name those days, but right now code.xwiki.org does >> not sell anything, so that would be wrong. >> >> So that would be Extension Repository for me. >> >> Concerning the data model and UI, I share most of what has been >> proposed. Some random remarks : >> - I like the experimental/beta/stable flag. >> - XRCode.DownloadClass should be XRCode.VersionClass IMO >> - "extension: page of the extension it is part of" for me this is not >> necessary, I would store both the XRCode.ExtensionClass object and all >> version objects in one document. >> - I don't think we need "minversion/maxversion" for the ExtensionClass, >> if we have this information in all Version objects we can draw the >> compatibility table. But that means trusting publishers will actually >> fill in that info for all versions and keep it up to date. >> - I don't like the livetable right at the top of the main page. My idea >> of the main page is something in the flavor of >> https://addons.mozilla.org, with a sexy intro that shows what are >> extensions, and then lists of "featured" and "popular" extensions for >> example. The full live table would come after that IMHO. Note that now >> that I look at addons.mozilla.org I think the idea of collections is >> interesting for us too, especially for the time we don't have an >> extension manager that can fix the dependencies issues. But that's >> another discussion :) >> >> Jerome. >> >>> I believe we should make this not feel "technical" but understandable >>> by non technical users. >>> >>> Any other ideas of prefixes or suffixes or other names before we start >>> a vote ? >>> >>> Ludovic >>> >>> >>> >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
