On Tue, 1 Mar 2011, Nils Kneuper wrote:
# 1) Add another flag to the <version> entry # Adding a 'type=' entry here will allow to specify if this application is a # "release" or an "alpha" or "beta" version. A possible usecase of this would # allow some "closed beta test" via package repositories only allowing registered # users (of a special group) to get the package/application/pnd. If no 'type' is # specified, 'release' is to be assumed. This means that the <version> tag can # look like this after the change: # <version major="1" minor="17" release="3" build="4" type="release"/> # This change requires no changes in libpnd itself since at the moment the version # tag is not respected/used anyway.
"type"; "stage" might be a better term .. 'alpha stage'. But 'type' might allow for wider use.
Is type/stage/whatever locked to specific enumeration: ah, I see, it is "alpha", "beta", "release".
Your example of "closed beta" is not supported by this.
A side question is ... this could almost be handled by the repo, not the pnd-file.
ie: Is a single pnd-file posted for 'closed beta', and then released to public when good? If we build in 'closedness' to the spec, then the file would need rebuilding just to reflect this status.
I don't think a 'visibility' (open, closed) etc should be in spec .. its just going too far.
So type/stage/whatever to define alpha/beta/release seems okay; lets not go into any further.
# 2) Change how <title> and <description> are listed # At the moment it is already possible to have several titles and descriptions
It is a drag to change the working XML just to make the 'validator spec' happy, but if we must, we must. It is actually something we talked about before _anyway_, but ended up not going with sub-groups for no good reason, so I don't mind doing it.
I think we will support both modes of PXML in libpnd, so as to not break any existing apps; users of the new schema/validator will have to conform to the revised spec, but the old spec files will still be acceptible to libpnd.
# 3) Add a way to specify the license of an application # At the moment there is no way for a packager/author of software to define the # <licenses> # <license name="public domain"/> # </licenses> # The reason to call this 'license' is that every software comes with some form of # license (a valid entry would also be 'do what you want with it'!), but not every
We should define in the spec some common ones. ie: is it one word, or free form? And for "public domain", always enter it as "Public Domain" (say), so that repo's can do something easy with it. <- unenforcible of course.
# 4) Add information about the 'package' in PXML # * I want to have this block mandatory to pass schema validation. The main reason # for this is to make it easier for package distribution systems. They can just # scan for this block and are done and don't have to look at the <application>
Note that any sane repo must be able to handle non-packaged files. ie: existing pnd files, and stuff that is non-pnd (pdf's, zips, theme files, conf files, shellscripts, etc etc.) ie: Repo should have pseudo-package implied by contained app/content in absence, so we leave that out of spec :)
# * Here is an example of what a (rather) complete <package> block looks like: # <package id="sample-package">
ID being defined as: - reasonably unique (same as for pnd unique-id); unregistered, but made to be unique - not expected to be displayed except as developer crap; it is not to be used for filenames or shown to users - what form? spaces? punctuation?
I didn't check the xsd for it.
# Now I am looking forward to your constructive criticism about this proposal. I # hope I provided enough reasoning for the respective blocks (especially when
Very good!
As always, thanks for converting all our IRC chatter into something workable :)
# If this is accepted as proposed here the following things would have to be done: # * Implement "2) Change how <title> and <description> are listed" in libpnd.
I'll take care of it
# * Upload "PXML_schema.xsd" and "PXML_schema_plaintext.xml" (as well as possibly # the example files) to [1]
Probably at the same time
# * Update the documentation in the wiki [2].
...... you? ;)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.