Thanks for your opinion :)
But the problem resides at another level (and here I'm sorry because I
supposed everyone was familiar with how PloneSoftwareCenter works).
In PloneSoftwareCenter, there is no such thing as assigning an OS (or a
platform) to the project.
Rather, the OS/Platform is assigned to the single downloadable file that
belongs to a release:
PloneSofwareCenter
|
--- Project
|
--- Release
|
--- File (here gets assigned the OS)
So, I can have the project "epiphany". Project "epiphany" has only one
release: "1.0". Release "1.0" contains 4 downloadable files:
epiphany.exe(whose OS attribute says "windows"),
epiphany.dmg (whose OS attribute says "mac os x"), epiphany.rpm (whose OS
attribute says "linux") and the source distribution of the release
epiphany.tar.gz (whose OS attribute says "all platforms" because from a
theoretical point of view I can compile and run it on any platform that has
a gcc).
This is a brilliant approach. If release 2.0 adds support for BeOS, I don't
have to modify the Project object and add BeOS to the list of supported
systems: I just add the downloadable file.
However, DOAP reasons along different lines: the OS/Platform attribute has
to be associated to the project, and only if the project is OS-specific.
In order to have a list of supported operating systems for a project, my
code follows the simple algorythm:
* Retrieve all the downloadable files associated with a Project
* Reads all the OS/Platform attributes of each downloadable file
* Filters duplicates and all and just returns the attribute list
The problem is that, if I take the example I gave before (epiphany) I end up
having four values: "windows", "mac os x", "linux" and "All platforms".
What would DOAP do? Write no os attribute, because the project isn't os
specific.
What does my code do? Writes four os tags containing the four values. Now,
if the light went down and there is just a siren and a blinking red light,
don't worry, that's the bug alert.
I should somewhat treat "All platform" in a different way, but I can't just
rely on the name.
Anyway, after thinking about it while coming home on the bus, I came to the
conclusion that the only solution that works is the one suggested by Martin
and that I mocked as "KDE-ish" (let the user, at configuration time, decide
if a value represents "all platforms", or, in a more formal way, if the
value triggers the deletion of the os tag when encountered).
This means modify some stuff, write migrations scripts, and test them (the
migration scripts: and to me doesn't look like a thing you can do in a
couple of seconds).
This is mainly because I suspect there is no way to automate migration
scripts tests, and they have to be done manually, and you want to be *damn
sure* that things in a migration script works well.
I won't merge in trunk until this is corrected though: because we don't
generate a correct DOAP right now. Is it possible to add DOAP after the
release? (even in a short span: like a couple weeks)
--
Simone Deponti
-------------------------------------------
- Oh wait, which ones are we Linux guys again, Rebels or Empire?
- Microsoft is the Empire. Apple is the Rebels. We are the Ewoks.
_______________________________________________
gnome-web-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-web-list
