Re: PloneSoftwareCenter DOAP
- From: "Simone Deponti" <shywolf9982 gmail com>
- To: gnome-web-list gnome org
- Subject: Re: PloneSoftwareCenter DOAP
- Date: Sun, 25 Feb 2007 13:38:28 +0100
I'd be happier if there were some passing tests before we merge. Why is
it a problem?
It's not a problem per se, I just need to write the tests and it'll take me time, so this means atleast another week/week and a half before merge. I don't know if wgo can wait all that much.
You need to consider migrations here. If you change the value and we
upgrade PSC on
plone.org, will eveyone who had "All platforms" (very
common for Plone) find that their selection is invalid?
Yeah, we'll have to migrate the content. The problem is simple: the DOAP spec says that you should put the <os> attribute only when the product/project is OS specific.
In PSC however, we have no operating system associated to the project but rather, we have it associated to the release file. This is not a big deal, since I simply do a catalog search to get all the PSCFile and PSCFileLink contained in my project, extract the list of os supported from them and I'm basically done.
The problem is that by doing so I end up writing in the feed something like <os>All platforms</os>. This isn't a great example of "adhering to the specs" and honestly I don't like it at all.
Thinking of the possible solutions, I came to these three solutions:
1. In DOAPView, filtering the "All platforms" keyword somewhat. Doesn't work because "All platforms" can be changed for example into "All operating systems" by the user in PSC configuration.
2. Making sure that the "All platforms" choice has always the same value and then apply solution one. That's what my proposal was about, simply enforcing a value for "All platforms" and taking that out from the user control. We can also think about keeping "All platforms" as both label and value, but enforcing them with the patch I proposed. Anyway, this solution has a drawback when it comes to internationalization: I have yet to see how we can fit this with the i18n system (there is a way, though, by directly calling translation_service.utranslate() from the vocabulary method).
3. Decide we do not need the OS attribute exported into DOAP, and skip it.
I still favor approach number 2: If instead of none we use "All platforms" we shouldn't have migration issues on
, although someone else might if in his setup he changed "All platforms" to something else.
Hope I have explained myself well.
- Oh wait, which ones are we Linux guys again, Rebels or Empire?
- Microsoft is the Empire. Apple is the Rebels. We are the Ewoks.
] [Thread Prev