apps.open-pandora.org offline?


I hate to say it but..


profesionally maintained?


- dev requests to udpate data.. ignored (for lack of time, single admin and all)


- its down right now .. thats not professional ;)


- massively out of date historically, since its crummy in a lot of ways; hence having a robot-person go through to udpate pnds, but doign so badly.. and also meanign devs don't own their own work in the thing, so can' tupdate anything anyway


- ignores all community driven standards; ie: the repo spec and so forth. If it added support for repo spec, all the existing tools would _just work_ on the pandora, like they do for repo; why not add the repo spec?


... etc :)


Thats the problem; goign on your own way is fine, this lets you do things differently and/or above and beyondf what standards allow; but ignore the standards and will fo the devs and community as well, is pretty 'bull headed annoying' :)


ie: sebt3 is one, mcobit is another, notaz another, etc.. the top devs are all annoyed and don't want their stuff there. Thats a hint :)


No one has anything against your appstop, but for its technical and philisophical letdowns. Why is it that notaz' app is still (or spent a year or two at least) with mispelling in the name, that he couldn't correct, and no one would do for him, for instance?


With it being so unprofesional historically, why would anyone believe the new one to be any better, when core points are still not being addressed. (repo spec being the big one.)


The main benefit to the dl.openhandhelds archive is that it supports non-pnd (ie: pdfs, zips, whatever.) I think milkshake really needs to add that to the repo, so that it could be central to all things.. take some design changes and probabyl some repo-spec changes, but its worth doing; right now, there must at least be repo and dl.open to cover all the bases (ie: think of things like UI skins, that are not executables.)


jeff


Taking the details from the pnd is the only way to fly; making the dev/uploader re-enter it all is asking for errors and out of sync problems.


If the info in the pnd is in error or sucky, the dev shoudl fix it, or people will down vote it.. self correcting.


jeff

You could argue many of the points you're making about the repo too.


What I'm suggesting, and what we have volunteers ready to do is maintain apps as well as the forum is maintained. Wikipedia style.


Your suggestion here is to just keep going with the mess we have? I don't think that's very professional or a solution in any way.
 
I'm confident that the Repo could be brought up to scratch, but we've still got the issue of packages in Apps which haven't presently been posted to it.


I, too, am frustrated by the lack of good screenshots in particular, many are the wrong size, obviously not taken on the Pandora, or simply missing altogether. Descriptions fare slightly better, but still need some serious work.


There's a new Repo layout in the work designed to be all-out responsive, much improved from a usability perspective and generally cleaned up. I am also pushing to get various features added, and some better integration with PNDManager for some Google-like download queuing.
 
Why do I have a feeling of Déjà-Vu here...?


NO ONE is against moderating.


NO ONE.


If the dev is okay with that (simply add some "I'm fine that moderators improve the description and screenshots" on the upload dialogue, and that's it).


No one complains about it.


WHAT everyone complained in the long, long discussion we had half a year ago about it is why you wanted to reinvent the wheel and code a new appstore (without JSON-API) when the current existing one could be improved.


I'm pretty sure that if you code and release an appstore with all these features (most importantly JSON-API so that everyone can continue using PNDManager right away), no one would complain and be happy.


But I'm also pretty sure that if you code and release an appstore that has all these features but is missing the JSON-API, everyone will complain - as it will be a MAJOR downgrade to what we currently have.


So:


Release an appstore with all the features needed incl. JSON and automatic PXML-extraction: Everyone happy.


Release an appstore with all the features needed but withou JSON and automatic PXML-extraction: Everyone will continue to use the repo, as it can be used in a way more convenient way.


It's as easy as that.

I'm confident that the Repo could be brought up to scratch, but we've still got the issue of packages in Apps which haven't presently been posted to it.


I, too, am frustrated by the lack of good screenshots in particular, many are the wrong size, obviously not taken on the Pandora, or simply missing altogether. Descriptions fare slightly better, but still need some serious work.


There's a new Repo layout in the work designed to be all-out responsive, much improved from a usability perspective and generally cleaned up. I am also pushing to get various features added, and some better integration with PNDManager for some Google-like download queuing.

That's a pretty good approach I like :)
 
Theres not too much mess now .. everyone goes to the repo.


The mess is that things are not yet all in the repo, so you ahve to check occasionally dl.open, apps.open, the forum, or the wiki; when files are only in dl.open or the forum or the wiki, thats just a lazy dev who didn't bother to want to upload it anywhere, and in that case, that problem will continue.


So the only real 'mess' is when things are in app.open and repo, and thats just due to app.open being earlier, and being linked on the main pages, so there is a political divide (highly unfortunate.)


I think everyone is pro many repos -- single poitn of failure is pretty bad, and it promotes competition/difference. But I think all repos need to support the community driven repo spec.


Make your own app store -- GREAT! -- but publis the API its NOT HARD. And then all the existing tools _JUST WORK_.


Why woudl you resist that?


Thats the question that people have been asking you for years. Your response historically has been 'well I made my own repo spec' (you didn't, or you didn't publish it, same thing) and means 'I ignored the community spec'.


Don't go alone on the published spec; use it, and if it has shortcomings, we can tweak it. Easy, we make the rules, we can tweak the spec :)


jeff


edit: sorry for typos, typing quick while in meetings and people buzzing around :)
 
Last edited by a moderator:
Sorry everyone - I hadn't meant to start an argument with that initial post.


Is there someplace - an FTP server or old link - where I can get the PND files that used to be there?

Installing the apps is WAY more easy with the repo at the moment.


Start PNDManager, select the game you want (or search, etc.), click on INSTALL and that's it.


It's as easy as it is on Android, though I find the PNDManager more comfortable than Googles Playstore.


WAY more easy than using any webbrowser.

PNDManager? Is that different from PNDstore?


If PNDManager is better, why is PNDstore included in the ROM and PNDManager is not?


On a new-out-of-the-box machine, how would I find PNDManager to install it?
 
PNDManager? Is that different from PNDstore?

A LOT. PNDStore is just a simple list, PNDManager a fully fledged app like the google PlayStore.


preview-4.png
preview-2.png



preview-3.png
preview-1.png


If PNDManager is better, why is PNDstore included in the ROM and PNDManager is not?

PNDManager needs more recent QT Libraries than we have in our current OS, so it won't work (or need too much space)


It will be included in .next, the next major OS Update (can still take a while).


If you check the Quickstart Guide of the OS, it actually suggests to grab PNDManager,

On a new-out-of-the-box machine, how would I find PNDManager to install it?

Either use PNDStore or get it here:


http://repo.openpand...pndmanager-bzar
 
Last edited by a moderator:
- dev requests to udpate data.. ignored (for lack of time, single admin and all)


- massively out of date historically, since its crummy in a lot of ways; hence having a robot-person go through to udpate pnds, but doign so badly.. and also meanign devs don't own their own work in the thing, so can' tupdate anything anyway
Yeah these were huge problems, I (and some other people) have had so much bad experience because of this that I don't want my stuff to be ever uploaded there again. Not to mention it didn't even have some app names right.
 
Theres not too much mess now .. everyone goes to the repo.

Not to be too pushy - but which one is considered to be, "the repo"?


I'm guessing: http://repo.openpandora.org/


It's good - but there are things missing from it that were present on the old apps site.


My larger concern is that there are several applications that were present on


http://apps.open-pandora.org/


that are blacked out for the duration. Vulture's Eye is a quick example. I don't know where else, if anywhere, that pnd can be found.


If we're going to centralize around 'the repo' - fine, but lets figure out how to get the rest of the applications populated into it.


If we're going to have a banging new http://apps.open-pandora.org/ site - fine. But shouldn't we also have access to the applications that were present before it went into redevelopment? Maybe on an additional URL?


Thank you.
 
Grench: I have them, I've got all PNDs ever uploaded anywhere ;)


We'll extract the PXML Data out of those, check which ones are missing and then will contact the devs of those apps to get the permission to upload them or ask them to do it themselves.
 
The repo is good as it is - I don't see any need to have other repositories with different API or functionality. Just all focus on improving the repo we have! In terms of core functionality it is nearly perfect already, it could use some additions like better comment organization, preview video, moderators who can approve PNDs to be more visible (i.e. non-approved PNDs invisible by default, but of course optionally visible) and modify the PXML in case some fields are missing or incomplete, etc.


I don't think more repos is better - yes, single point of failure is bad, but that should be solved by adding mirrors that are auto-synced to the central repo, not by having multiple mutually incompatible repos.
 
I don't think more repos is better - yes, single point of failure is bad, but that should be solved by adding mirrors that are auto-synced to the central repo, not by having multiple mutually incompatible repos.
I disagree. There are going to be some things which are necessarily ambiguous in their usefulness: one person might like one feature while another might find that particular feature to be a setback. If this weren't generally true there would be no emacs/vi debates. Different applications doing the same thing (repositories in this case) with slightly different philosophies can compete and innovate in ways that a single application would simply stagnate at. I fully encourage Craigix to show us his vision of what an app store should be, and I've been encouraging him for years, ever since the first time apps went up and people started making suggestions.


That being said, I do agree that multiple mutually incompatible repos would be a bad thing. The json API was designed with feedback from all sides to allow repositories to be 100% compatible with each other: PNDManager should be able to connect to each software repository with no problem; other front ends can then also be designed with different features and philosophies and those as well should be able to access wherever the PNDs may be stored. Craig could show us his vision and it could be pretty good but if it isn't so mind blowing awesome that the entire market wants to switch then it will fail for incompatibility, or at the least it will make the user experience less than ideal since they'll now necessarily have to visit two completely different sites or run two different applications to get their stuff. If he does make it compatible then they only need one: they can visit Craig's appstore and still get stuff from the repo and vice versa.
 
I think it would be useful if, given that the vast majority of .pnds ever created are somewhere on ED's server (wrapped up wikis, forums etc), there could be a crawler that hunts through everything,and creates a publicly (if you have an account) editable entry for it on the repo (or appstore!). It could also crawl through new uploads. Once these auto-created, public entries were there, you could apply to a mod for ownership of the page (if you are the author) or add extra information manually like a wiki.


If the .pnd is well formed a lot of info should be immediately available - the crawler should also harvest the forum post it came from and suchlike if possible.


This would only work once the repo has a few more features, but would help a lot with unification.
 
It'd be nice if each repo we had mirrored each other ;)
The JSON interface means that each repo could reference each other repo's system: no need to mirror anything, just ask the remote repo for information.

I think it would be useful if, given that the vast majority of .pnds ever created are somewhere on ED's server (wrapped up wikis, forums etc), there could be a crawler that hunts through everything,and creates a publicly (if you have an account) editable entry for it on the repo (or appstore!).
This would lead to the problem with Craig's appstore which lead to the creation of the repo: who owns the PNDs it finds? How does it keep track of beta vs release? What if the developer doesn't want it published on that collected site? If the developer uploads a newer version somewhere else how will the spider know? You can end up with multiple versions, including outdated versions that the developer has no control over. This caused problems before, so when Milkshake created his repo he included the policy that only the person who created and maintains the PND (or an authorized proxy) should upload that PND.
 
Back
Top