From skeezix@skeleton.org Thu Mar 3 22:10:08 2011 From: Jeff Mitchell To: firmware-dev@openpandora.org Subject: Re: [Firmware-dev] PXML specification: proposal of new specs (including sample files and schema) Date: Thu, 03 Mar 2011 16:10:04 -0500 Message-ID: <20110303155421.S18387@fw.skeleton.org> In-Reply-To: <4D6C34B7.8040203@gmx.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5707047823527311502==" --===============5707047823527311502== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 1 Mar 2011, Nils Kneuper wrote: # 1) Add another flag to the entry # Adding a 'type=3D' 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 regist= ered # 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 tag can # look like this after the change: # # This change requires no changes in libpnd itself since at the moment the ve= rsion # tag is not respected/used anyway. "type"; "stage" might be a better term .. 'alpha stage'. But=20 'type' might allow for wider use.=20 Is type/stage/whatever locked to specific enumeration: ah, I see,=20 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,=20 not the pnd-file. ie: Is a single pnd-file posted for 'closed beta', and then=20 released to public when good? If we build in 'closedness' to the spec,=20 then the file would need rebuilding just to reflect this status. I don't think a 'visibility' (open, closed) etc should be in spec=20 .. its just going too far. So type/stage/whatever to define alpha/beta/release seems okay;=20 lets not go into any further. # 2) Change how 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=20 spec' happy, but if we must, we must. It is actually something we talked=20 about before _anyway_, but ended up not going with sub-groups for no good=20 reason, so I don't mind doing it. I think we will support both modes of PXML in libpnd, so as to not=20 break any existing apps; users of the new schema/validator will have to=20 conform to the revised spec, but the old spec files will still be=20 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 t= he # <licenses> # <license name=3D"public domain"/> # </licenses> # The reason to call this 'license' is that every software comes with some fo= rm 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,=20 or free form? And for "public domain", always enter it as "Public Domain"=20 (say), so that repo's can do something easy with it. <- unenforcible of=20 course. # 4) Add information about the 'package' in PXML # * I want to have this block mandatory to pass schema validation. The main r= eason # for this is to make it easier for package distribution systems. They can ju= st # 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.=20 ie: existing pnd files, and stuff that is non-pnd (pdf's, zips, theme=20 files, conf files, shellscripts, etc etc.) ie: Repo should have=20 pseudo-package implied by contained app/content in absence, so we leave=20 that out of spec :) # * Here is an example of what a (rather) complete <package> block looks like: # <package id=3D"sample-package"> ID being defined as: - reasonably unique (same as for pnd unique-id); unregistered, but=20 made to be unique - not expected to be displayed except as developer crap; it is not=20 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=20 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 poss= ibly # 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. --===============5707047823527311502==--