18
sunsnapper:
Nice of you to say I have the lead. Actually, if you take a look at the thread, it was you who started it all, so we could say you have the lead. Then again, the lead should belong to whoever makes a contribution, and in this sense mikhail has the lead.
It's really good to see the interest in this matter. As I've said many times in the core team's conversations, I see myself more as a catalyst than as a leader, so here are some more thoughts regarding what's been said here.
It's a good idea to build a MyModules module. Even though Herko has a point about the difficulty of having separate repositories, XOOPS users need the choice. What would such a module have? Let's see:
a. An ordered list (MyDownloads). The admin should be able to select a default order. The list could have two versions (Spotlight): single line with linked title and double line (the first one, the linked title; the second one, a delimited number of characters from the description.
b. Blocks for Recent modules, Top modules, maybe Top Authors...
c. Each register would have:
--- The module's name (with link to the download. Or should we use several links for the different archive versions?).
--- The module's author (linked name)
--- The module's version (number and date)
--- What's new (short description of most recent change)
--- The module's description (up to 255 chars)
--- The module's screenshot (should we talk about the possibility of linking to a gallery?)
--- The XOOPS version (if applicable)
--- Link to report broken link
--- Link to send module's link to a friend
--- Link to suggest a feature
--- Rate this module
--- Comment this module
--- Links to the Forums' threads on this module
--- Links to former versions of the module
From all this we can see it's mostly a reconfigured MyDownloads module. Shouldn't be that hard for the daring xoopsers around.
An important matter has to do with multilanguage capacities. I've said elsewhere we're looking at how to solve this in the long term, but in the meantime, I'm not sure about this: should we use the hack in the modules site? This way we could have several languages in the same site. The implications are complex, and one of them has to do with the often neglected issue of maintaining content. It's still an open discussion.
I'd say mikhail's ideas are as good as they are fast. As someone who lived the 8.3 era, I welcome the opportunity to use long names. But I also try to be practical. Names that are too long have also implications. I'd go for a somewhat reduced version, maybe:
m205_modulename_version.tar.gz /.zip
like
m200_addresses_1.5.tar.gz
(Of course, we might include the author's name in the line containing the module's name.)
This stuff about setting standards should not stop here. I like the idea about having inside the archive the real directory name with all relevant stuff. And we should strive to apply the file and block names described in the module kickstart guide (in the Wiki).
One possibility I've been toying with is the use of an expandable tree to list the modules. Something like:
+ Linked category name one
+ Linked category name two
- Linked category name three
.. - Linked module name one
.. - Linked module name two
.. - Linked module name three
+ Linked category name four
We could store an abbreviated description of each category and module in a string of about 80 chars, and on mouseover we could show somewhere either the category description or the module's short description. What do you think of this?
I'd also like to have the whole bunch of modules uploaded and available, but I'd like to suggest another important task before that. Of course this is a personal opinion, and I hope the many authors don't think it a bad idea, but I'd say all the modules need to pass through a process to make them... er... uniform.
What do I mean? I say all the modules need to include (and many don't):
1) A README file with concise installation instructions, including the data that'll be contained in the repository (See above). This should also include a list of the files contained in the archive.
2) A carefully reviewed set of language files. Don't get me wrong, but there are authors that are excellent at handling code, but whose domain of the language isn't at par, so we should check this.
3) A description file, like the .NFO "standard". This should say what the module does. I've installed many modules just to see what they are...
4) Please add here your own ideas.
That's all I can think of at the moment. Excuse the long post, but I do think this is an important matter for the whole community.
LAST MINUTE ADDITION. I just read onokazu's post. Seems like a good idea, and the only additional comment I'd add is that I'd prefer to abbreviate xoops' name. All in all, the relevant point is we need to have a standard and to follow it.
Cheers.
