Re: PloneSoftwareCenter DOAP

["Simone Deponti" <shywolf9982 gmail com>]

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.