Special attribute "Native Pandora App" for the repo or PND-XML, so that native apps get the exposure

[porg]

Imagine a newcomer: How can s/he easily find native (=original) Pandora apps?

... without studying hundreds of blog posts, forum articles, repo detail pages, etc!

It would be wonderful if you had one place, where you could browse apps particularly made for the Pandora.

And as the repo meanwhile is the main place for software browsing & downloading, I suggest to implement this native app filter (& showcase) there!

Thoughts about its implementation (in case some-one is willing to):

1) a) Technically seen it may be good to add a new field to the PND XML specification itself, so that this attribute could also be facilitated for filtering/sorting within PND PND launchers/managers/etc.

B) But to not complicate things I suggest to start with a simple flag (boolean) or attribute (which can take multiple values, for now its value can be nil or "native", later new values could be added ("port", "rewrite", etc)) in the repo. Because the main purpose of this is, that people can discover native apps, not necessarily filter installed ones on their Pandora. Because if they liked them, they anyhow remember them or fav'ed them with the available mechanisms of their GUI / launcher, i.e. by putting them to sd/pandora/apps or ../desktop instead of ../menu.

2) Later we could add further possible attribute values such as: "port-crude", "port-fine" (for apps ported with lot of effort to be exactly tailored for the Pandora utilizing it as best as possible (screen-size, controls, UI adaptions, interplay with system/other-apps)), "rewritten" (concept copied, but completely re-developed for Pandora). And my suggested attribute could be further differentiated: "native" (the game was initially published to the Pandora only, maybe later ported to other platforms), "native-multi" (the game was initially published to multiple platforms, among them to the Pandora).

3) a) So far the repo got these release types (URL variable: "rt"):  alpha | beta | release | commercial ("com")

B) From an information architecture perspective, my suggested attribute is not a further of your release types, but a new filter-attribute. Because an app can bear the attribute native AND any of the release-types (alpha/beta/release/commercial), but you could assign only one (OR choice). Thus a new attribute.

c) Question is, what do we name this attribute? "Nativity", "Originality", "Platform" or a combination of these?

P.S.: I usually post repo feature suggestions in the according thread, but as this issue is of broader concern, possible also an addition to the PND XML specification, I posted it here.

 

[ptitSeb]

On a commercial world, that's called "exclusives titles"... But here, in an OpenSource worlds, such things don't really exist

I thinks the "star rating system" (which I don't really like), is basically already a crude system to classify "port-crude" and "port-fine". I'm not sure I get the point of adding this kind of attibute.

But, you can think of a label "designed for Pandora", given by an independent jury to software (port or custom-made) that perfectly fit the Pandora screen, control-scheme, and so on (and you can have different levels, for example, my "build 03" of the *.emu, with control not fitted for Pandora by default, wont have the gold label, but only silver)...

 

[ShleeDragon]

I don't care about the portiness.... I care about the gold standard.

If a port has been tested and works perfectly on the pandora without fault... mark it as a gold applicaition.

There might be ten ports of a SNES emulator.... but only one might be a gold perfect PND.

Id mark the PCSX release as a gold PND.

 

[Neelix]

An interesting Idea.   I like it.  I've actually pondered suggesting something similar myself,  though my use-case is slightly different to that suggested here,  the same type of mechanism could work for both.  

Basically I'd like to have a way to easily distinguish between PND's which are complete programs or games (no additional files required),  PNDS which rely on data from another source, (eg data files from a commercial game)  and Installers. (run PND to install/uninstall some files to the rootfs)

If you implemented it as a tags system it would be quite extensible.

eg:  if you added optional <tags> and <tag>  elements to the PXML (I'd put them in the <package>  area)  then I could see it working something like this:


  <tags>
     <tag name="Native"/>
     <tag name="NoAdditionalData"/>
  </tags>

Then you could  add code to filter based on a few commonly agreed upon tags, or allow filtering on a custom tag.

- Neelix

 

[porg]

@Neelix differentiation standalone/requires-data/installer: Also useful. I would assume stand-alone as the rule, and requires-data or installer as the exception, thus would flag them.

@Others: You are right, the differentiation port-crude and port-fine is bureaucratic overkill. Who would decide? Would need jury! Not suited for a FLOSS community. The combination "port" + rating is better suited as it is crowd sourced, and says enough. (For rare exceptions were people rate a poorly ported app quite high, it must mean that the content is so overwhelmingly good, that they formal porting mistakes are willingly ignored)

@milkshake: Do you consider to implement?

 

[gotwake424]

@Neelix differentiation standalone/requires-data/installer: Also useful. I would assume stand-alone as the rule, and requires-data or installer as the exception, thus would flag them.

@Others: You are right, the differentiation port-crude and port-fine is bureaucratic overkill. Who would decide? Would need jury! Not suited for a FLOSS community. The combination "port" + rating is better suited as it is crowd sourced, and says enough. (For rare exceptions were people rate a poorly ported app quite high, it must mean that the content is so overwhelmingly good, that they formal porting mistakes are willingly ignored)

@milkshake: Do you consider to implement?

@milkshake? where did he post in this thread? or am I missing something?

 

[Kumaki]

I like making certain apps gold.

Maybe gold, silver and bronze.

 

[Neelix]

@Neelix differentiation standalone/requires-data/installer: Also useful. I would assume stand-alone as the rule, and requires-data or installer as the exception, thus would flag them.

*nods*  that makes sense.  

I've also realised that the it's the repo spec that would need to be extended,  not the pxml spec as I'd originally suggested, but the general idea is the same.

- Neelix

 

[porg]

@milkshake? where did he post in this thread? or am I missing something?

MilkShake runs the repo. So I am addressing him. Hope he reads as well.

If I get no reaction within 2-3 days, I'll notify him via PM.

(Dunno if the board software is intelligent enough to notify "user" if it detects "@user" somewhere in a post)

 

[Binky]

(Dunno if the board software is intelligent enough to notify "user" if it detects "@user" somewhere in a post)

Don't think so

 

[ssokolow]

To be honest, the main thing I care about is the availability of source code. I refuse to grow attached to anything which is locked to a specific ABI version of a specific OS for a specific processor architecture... especially when said ABI is the OS of a piece of non-commodity hardware. (I play most of my games in emulators, DOSBox, and Wine since x86 is commodity hardware (in the case of Wine) and the open source emulation/API wrapper layer provides ABI isolation... and, surprise surprise, the only stuff I've had trouble seamlessly moving to my Pandora was stuff running in Wine like Knytt Stories)

The only thing that really annoys me about the repo is how much time I have to spend manually verifying whether or not each PND has source available (Especially when the porter's website is poorly-organized).

I suppose filtering against exclusives would serve as a very rough surrogate for that since ports are more likely to have their source available. (It'd also help since I prefer to play games and use apps which I can juggle back and forth between my desktop and my pandora with minimal effort)

 

[gotwake424]

@milkshake? where did he post in this thread? or am I missing something?

MilkShake runs the repo. So I am addressing him. Hope he reads as well.

If I get no reaction within 2-3 days, I'll notify him via PM.

(Dunno if the board software is intelligent enough to notify "user" if it detects "@user" somewhere in a post)

ahh gotcha, don't think it does

I thought I was missing a post from him or something along those lines

 

[Rockthesmurf]

On BlackBerry's newly launched platform, 'BB10' they have a 'Built for BlackBerry' program, you can submit titles which work very nicely on the BB10 devices (they don't have to be exclusive, but if they are ported they need to integrate well, making use of the Scoreloop awards/leader boards, of BBM messenger, must not crash, must be full screen, run well, have good controls for the device, etc). Successful applicants get a little overlay they can put on their icon to indicate it is 'Built for BlackBerry' and they sometimes have banner features on the store for Built for BlackBerry applications.

Obviously the above relies on a store with a submission process/gate keeper to test/reject and doesn't fit onto what we have here on the Pandora. But I just thought I'd mention it as a reference point.

 

[porg]

I suggest a solution which works entirely without administrational staff/effort. Leave the:

• "native / native to multiple / ported" flagging to the responsibility of the maintainer,    (=factual)
• rating & reviewing to the community.   (=popular, qualitative)

 

[skeezix]

I had been thinking of tagging as well, to make the PXML 'extensible' in haphazard informal fashion. Like hashtags etc .. something that may be optionally used by consumers, but can be ignored by everyone as they see fit. Standardized only insomuch as peopel standardize them in usage.

I had been thinking simialr to Neelix, though slightly differently:

<attributes>

  <attribute key='foo' value='bar'/>

</attributes>

(where possibly the 'value' is untirely undefined; ie: as to suggest you coudl do valume1, value2, whatever you want.)

We'd have to place limits, just to make parsing (even with ignoring) sensible. ie:

- key is mandatory in an <attribute>

- one or more values - entirely optional

- any key present must be less than 64 characters, and pure alphanumeric (no whitespace)

- any value present must be ... same restrictions as key

Easy to implement for firmware -- entirely ignored! (PXML parsing already ignores things it doesn't understand.)

++ documentation on the pandora wiki in PXML specifications page .. easy enough to do

So it becomes work for consumers (repo, say.)

jeff

 

[_wb_]

It would also be useful to have a distinction between free and non-free, or actually between "Open source" and "Closed source" on the one hand, and between "Free", "Gratis but nonfree" and "Commercial" on the other hand, and the latter field could be different for the program and the data files.

Examples:

Widelands would get the following flags: "Open source" and "Free" for both program and data

Frogatto would get the flags: "Open source" and "Free" program, "Gratis but nonfree" data

Stratagus would get the flags: "Open source" and "Free" program, which needs "Commercial" data files

AquaVenture would get the flags: "Open source" and "Gratis but nonfree" for both program and data

KAMI RETRO would get the flags: "Closed source" and "Commercial"  for both program and data

 

[skeezix]

There is already preswent a license section, which can contain multiple licenses. Shouldn't that suffice?

ie: The consumer can look up the license to find its meaning.

Trying to contain all the nuances of a license in just a few words is probably hard.

*shrug*

 

[notaz]

I don't think adding new PXML fields would be useful, most released .pnds will never be updated and hence will never be flagged with anything. That's unless the PXML is modified by the repo itself, but that would be painful for milkshake to implement, plus there are .pnds released under closed licenses that don't allow modification of released binaries at all. I personally wouldn't like my released pnds to be edited by anything too.

What could be perhaps done is milkshake adding additional flags in repo database, like there is now "commercial" flag and somebody could hunt all the authors to fill the gaps, but even that wouldn't work completely too as many authors are long gone now.

And then again, who would ensure all those flags are correct, you'd need some authority to control it. Somebody can do a quick drive-by port and mark it "super-native-and-optimized" because he thinks it is, it's very subjective really.

 

[_wb_]

There is already preswent a license section, which can contain multiple licenses. Shouldn't that suffice?

ie: The consumer can look up the license to find its meaning.

Trying to contain all the nuances of a license in just a few words is probably hard.

*shrug*

Yes, ideally the license field is filled in correctly and sufficiently unambiguously. But it's kind of hard to make a repo viewing filter based on that field, because some people might write "GPL", others might write "GPLv2+", others might write "GNU General Public License v3", etc. Plain-text fields are not that easy to work with.

Several distros use the concept of "free" and "non-free", or e.g. in Ubuntu you have "Main", "Restricted", "Universe" and "Multiverse". It would be useful to have something similar on the repo, so that people like ssokolow and onpon4 can easily check only the Free part of the repo, or like Neelix suggested, easily check whether something is a stand-alone program or will need data files from a commercial source. It has happened to me more than once that I installed something only to get an error about missing data files which I'm supposed to extract from somewhere. Yes, typically you can find out about that before you install it by looking at the detailed information, but it would be nice if you could filter those out in PNDManager (actually in both ways: you could also be interested specifically in PNDs that work with extracted data files if you happen to have a large collection of old games).

 

[porg]

@Neelix: Thanks for pointing out the technical possibilities, nevertheless I adhere to notaz' arguments, that post-manipulation of absent maintainers' PND packages is potentially rude or worse a licence violation.

And then again, who would ensure all those flags are correct, you'd need some authority to control it. Somebody can do a quick drive-by port and mark it "super-native-and-optimized" because he thinks it is, it's very subjective really.

Solution:

Rule 1: By default: Only the maintainer can change that field in the repo. (And into the "informal" area of the PND. Why not?! Could be of use later & confirmed as harmless to the system by Skeezix)

If the maintainer did not flag a PND (yet), some-one from the community will inquiry, and that maintainer may add the flag.

Rule 2: If the maintainer cannot be reached, as he left the community,

Variant a: bad luck for the community. Still, in overall, enough packages will get flagged.

Variant b: OR we think about granting permission to a repo-admin who could flag "those orphans" (first should attempt to contact maintainer: Courtesy! Except if certain that maintainer cannot be reached or that it's ok for him/her). As said, qualitative judging should be left exclusively to the crowd's responsibility (rating & reviewing & the download numbers (popularity) also tell a story), the flag joyces should be objective (=factual) and easily unambiguously assignable (native / native to multiple / ported / possible other values too). I think this would be possible. I would volunteer to do that. (Together with others, so that it feels fun rather than serious responsibility, and I would do it here and then, on average maybe once a month a session of 2-3h).