My proposal is literally just to standardize a (couple of?) optional meta data parts in DBP such that software authors could say: "In this application's menus, I've put Confirm on the foo button, Back/Return on the bar button, and if you want to exit the software / get back to the menu of this software, that'd be the baz button." (plus, a way to indicate flipBX support would be needed for applications that support flipBX, unless flipBX isn't going to be a thing on the Pyra). No guidelines or anything?!?
I think this should definitvely included as an optional metadata element. This bears the opportunity to "standarize" some elements even afterwards as system that exist seperately just need to pick up the information. A scenario I could think of, could be Christoph.Krns guihints in combination with pmprogs overlay - plan: if the overlay could be aware / would be able to know which application is currently active (is this possible in the linux multitasking environment we are expected to have?) it could read that info and show it, so there would be no need for game-devs/maintainers to include the functionality. Or a more realistic example: the repo-client is able to provide a "quick-hints" area/window where users can pick up the most import buttons fast and easily
The most important is the format used for detailed descriptions of packages. This shouldn't bee too fancy, it should allow for some basic formatting and that's it. Videos and simlar content should be attached separately imo, as they are not included in the package file's metadata. What are the options here? Plain HTML is probably a pain, since you need to sanitize it properly to avoid scripts and crap like that running, but milkshake has the final veto on that.
HTML does not look that far off to me - at least its a well known standard with lots and lots of documentation and software that supports it out there. There is a chance of abuse that gets more probable if the software that wants to read it utilizes more complex standard components (like a webkit library). But this could be avoided in several places: the repo could be restrictive about what is allowed (something like "if description contains <script> nag uploader") the client could filter out everything except a specific set of tags or depending on what tech the client uses, the part that renders the description can be configured to ignore "active" content. Or use the most secure method and just filter the tags out and render the plain text.
What are the alternatives ? There is tex, but that seem too complex for what "we" are aiming for - or not ?
Next is documentation. Is that to be included the current PND-way (does it work well?) or should a separate system be used for it? A separate system means it'll probably be access by different means than through the program menu. Since the linux desktop is in a broken state and multi-level program menues are more or less unsupported, this might be a good thing, as a long long list of documentation could be annoying to look though. If a separate system is employed, it should probably use the same markup format as the description, to simplify codebases (and it makes sense to have it available via the repo too, I guess.) If it's just desktop launchers pointing to an html or whatever, then I guess format is whatever the dev feels like.
I think it works well in the sense of providing an easy way to bundle information with a package. But what I did not like about it was the part that provided access to it (on the Pandora) - putting them all together in one menu "folder" cluttered things up heavily and I was often confused when they had the same title.
I also suggest an optional changelog to be included in the package metadata. This should be a simple plaintext format that is both human and machine readable (so it needs a defined syntax.) An argument for machine readability is to allow a package manager to present changes from the currently installed version as compared to the one that can be updated to.
Should definately be in there
Preview screenshots are something I've had a hard time justifying being in the package. I hate the fact that I would need to update the whole PND to add or change screenshots. I think the DBP repository should store them separately, either a binary blob in a database or just stored in some directory on the server...
I disagree, Screenshots are important if you rely on other means of "browsing" the dpbs as slaeshjag already pointed out. I would rather see the ability to override the included screenshots with ones you can upload via the maintainer (web)interface, implemented into the repo.
What about "banal" flags like "multiplayer" [yes/no] ?
Is an override ability (much like on the Pandora with .ovr files) planned ?
