Updater for PNDs?

[Klaue]

I just read the tread abead err about preparing stuff for when the pandora arrives and thought "yeah well, I collect the PNDs and when the Pandora finally arrives they're all outdated.."


Then it struck me..


One of the things I liked the most about Linux is that all applications come from the same source and are updated through it (package manager). Now, PNDs are a whole other way of getting progs, so is there a way to automatically update them?


If not, would it be possible to be done?


The PXML spec has an entry for the Version (<version major='number' minor='number' release=number build='number' />), but I don't know if you can get the version in the app store without having to download the PND first (which would generate a metric ass ton of server load).


How about a package manager for pandora? (I vaguely remember something about there eventually being one)


One could probably implement it that way that only programs which set the home directory to $PANDORA_APPDATA (a to-be-made env var) and install themselves on the cards so that the NAND remains untouched are allowed. Or just make a package manager containing only PNDs or something

 

[EvilDragon]

Yes, it would work.


skeezix also thought about modifying apt-get to grab PNDs and update them on the SD Card... should be easily possible

 

[levi]

Something like that would be awesome; being able to do a pnd-get update && png-get upgrade to update all your PNDs would be fantastic.

 

[Klaue]

Something like that would be awesome; being able to do a pnd-get update && png-get upgrade to update all your PNDs would be fantastic.

well, if there isn't something like this allready when I finally get the pandora, I might do it myself.


Probably nothing too complicated.. A config file where you set the path(s) of your pnd directories, a pnd-update which does nothing more than compare the version tags with the app archive and a pnd-upgrade which installs those new versions - maybe even just an upgrade which does both.. But implementing a search, an installer, uninstaller, front-end and so on, no thanks


But maybe someone wants to make a full-fledged apt for PNDs (Advanced PND Tool?) complete with a repository and everything anyway.

 

[3jane]

I think you would be better off writing a new package manager from scratch rather then modifying an existing one. Apt has WAY more functionality then you would ever need for managing PND packages. A huge amount logic in most package managers is dedicated to checking and satisfying dependencies - that's kind of the whole point of them.


So, on to designing a new PND manager (pnd-man ?). You could maybe scrape the data you'd need from the app store, but a better approach would be to work with the store guys to make a proper repository-style package list you could grab with "pnd-man update". If you get this part right all the hard work is done. Stuff like "pnd-man search", "pnd-man install" and "pnd-man upgrade" could be accomplished with simple scripting.


I'm keen on playing with this idea myself...

 

[Klaue]

Yeah, modifying apt would be way too much work.


And after the answer from ED, I assumed a list of packages with their Version would allready exist.


Just one thing I wondered.. One might have to make an additional entry in the PXML. Assume you make a PND for, I dunno, GIMP. The Version-Tag would look like this:


<version major='2' minor='6' release='11' build='0' />


for the most recent Version. Now assume that whoever build this PND made a mistake (like writing the configs to the NAND) or improved it to run faster. The GIMP-Version would still be the same, yet the PND-Version would not. So you would need something like


<appversion major='number' minor='number' release=number build='number' />


<pndversion version='number' />


or alternatively


<version major='number' minor='number' release=number build='number' pndversion='number' />


Sure, you could just use a hash and assume that if the hash on the server is different, the version is newer, but that would be very scetchy

"pnd-man search", "pnd-man install" and "pnd-man upgrade"

$ pnd-man install justice!


What? Do it yourself.


$ sudo pnd-man install justice!


downloading zero wing..


set us up the bomb? [y/n] y


installing..


Move zig! For great justice!


...SCNR

 

[MarioPandio]

^Love it


will be great when something on these lines gets figured out by all you awesome tech savvy types.


I wait with baited breath...

 

[ibisum]

I think you would be better off writing a new package manager from scratch rather then modifying an existing one.

Puke!


Whats wrong with the Simple Updater for Pandora Applications? I've been using it, seems like it works to me ..

 

[3jane]

Whats wrong with the Simple Updater for Pandora Applications? I've been using it, seems like it works to me ..

Cool, I was unaware if it's existence! Obviously it would be better to extend the existing functionality of SUPA then to re-invent the wheel.


Although I'm not thrilled with the way the package metadata is gathered. It works as a proof of concept, but an official list from apps.open-pandora.org is definitely the way to go moving forward. Next week I'll try to work out who to contact about setting something up.

 

[3jane]

Thinking about this some more, the pandora app store has a perfectly good database of available packages. It also has a way to distribute PND files by http.


If you just combine what is already there, you could distribute a PND containing a dump of the database (or an extract of it) on the app store itself. The PND file would be updated periodically.


This would allow a lot of flexibility in designing the package manager on the pandora.

 

[Klaue]

Thinking about this some more, the pandora app store has a perfectly good database of available packages. It also has a way to distribute PND files by http.


If you just combine what is already there, you could distribute a PND containing a dump of the database (or an extract of it) on the app store itself. The PND file would be updated periodically.


This would allow a lot of flexibility in designing the package manager on the pandora.

Why work over PND? I mean, case one, a database reachable trough http: pnd-update -> http request to server -> server generating output from DB (JSON or XML) -> parse response. Case two, using PNDs: pnd-update -> http-request to server -> server collecting data to ram (instead of just writing it) -> server generating PND (probably costly) -> downloading PND -> extracting PND -> reading/parsing contents. Second one would be 3 steps more.


Something like


[{"app":"firefox", "appversion":"3.6.4.0", "pndversion":"1.0", "timestamp":"2010/10/18 08:37:55", "url":"http://appstore/firefox/ff.pnd"}, {"app":"gargoyle", [...]}]


(yeah, I always preferred JSON over XML - prob. faster to parse, faster to write and really simple)


would take way less time (and other ressources) to generate and parse than a PND, too.


Or do I get you wrong there?

 

[3jane]

Why work over PND?


...


Second one would be 3 steps more.


...

I was thinking that the PND would be updated periodically rather then generated on demand, so the difference is only one more step - but I digress...


The idea behind the PND approach was to make a recommendation the app store maintainers could implement with minimum development and fuss (increases probability of work being done!). As an added bonus, any tool designed to install/update PNDs would not need any additional dependencies.


Having said that, I did not consider the possibility of direct access to the database. From a the point of view of easy implementation this is a total win. It's also very flexible from the client implementation end.


It's the best suggestion I've heard so far. Nice catch

 

[Klaue]

Oh, don't get me wrong, I diddn't mean direct access to the DB.


While possible by making an account with only read rights, I never like having anything directly accessing the DB. One reason is security. A new MySQL bug and even read access could turn out to be bad, but that's probably just me being paranoid, and you couldn't prevent someone using it to just fire off costly selects one after the other.


Another reason is backwards compatibility. You could never change the DB structure without having to change the updater. For example, imagine the PND version was kept as a floating point number at first. Therefore, the generated JSON for this would be something like "pndnumber":"1.3". Now imagine that would later change for some reason to mayor, minor, release & build like the app version number. The DB would look wholly different (instead of just a float column on the main pnd table, you'd have an extra table for the pnd version and an pnd-version-table-id-column in the main table), so you would have to change the updater if it accessed the DB directly. If you use PHP to access the db, you could just change the code in it to but those fields together in a float again (mayor 1, minor 3, release 5, build 20 = 1.030520 or something).


While a code change would have to be done either way, the one on the server could be done by the same person changing the DB. Also, there might be multiple updaters (someone might want his PND to be the newest version every time it starts and therefore adds his own updating code to it using the app store).


Well, I digress a bit. What I meant is a PHP site that just generates JSON (or something other) from the data of the db, so it would be like this: client -> php -> database -> php -> client


Building JSON out of the database is really fast and easy to implement.