PND file names: include version number?

[hmc]

Hi guys,


PNDstore is an awesome beginning, and I know there is something in the works (forgot its name, though) which makes maintaining installed PNDs, installing and upgrading PNDs easy and convenient.


But for now (and for people prefering to maintain their installed PNDs manually) it would be a big plus, if each PND file name contained the version number of the contained application.


Asking for opinions:


IMHO it probably doesn't make too much sense to enhance the PND speicfication in that direction (that adding the version number to the file name is required).


But maybe the repo could be enhanced so that it always appends (if not present) the version number to the PND file name when the PND is uploaded or downloaded?


The alternative would be a small script, installed locally on each interested user's Pandora, which extracts the version numnber from the PXML.xml file and writes it into the file name.


This would be the wa I'd go for now, if such a repo enhancement deos not make sense / won't be done.


Daniel

 

[milkshake]

well I did have that idea and brought it up in the past when the repo was in its infancy but it was thought in the end to entrust this to the dev to chose what ever naming he wants for the PND

 

[lomaxx]

Including the version-number also has a disadvantage: When you implement the pnds in others scripts by using pnd_run.sh, then you have to change each script to the new version-number/name.


Not sure if that helps you, but the version-number - more than that - the whole PXML.xml-file is written in plain-text in the pnd-file. I used for some personal script a line like

mpoint=$(tail -n 600 <pndfile.pnd> | egrep -ao appdata=\"[^[:space:]]*\" | uniq | sed -e 's/^appdata=\"//' -e 's/\"$//')

to determine the mountpoint-name. Something similar should work for the version-number. Note that this mechanism is not 100% bulletproof, but from my experience it's working quite fine. I only search the last 600 lines of the pnd. Maybe that's not enough for some PNDs. There's probably also a more efficent way. I just try to get along with the little things i know.

 

[Mr Rob]

@hmc, your idea does have some merit, but I actually have the exact opposite opinion, where PND file names shouldn't contain version information (well, exact version information). Here is my use case:


I see Wesnoth has a new version (wesnoth-1.9.12-1.pnd or whatever), I copy it to a flash drive to put on my Pandora later, and now I can't simply copy it to my SD card, as there's already a wesnoth-1.9.11-1.pnd on there. Should I just copy it, I now have two wesnoth versions on my Pandora. Which is a bigger hassle if you're using ovr files (I use them to make a favorites category).


Does PNDStore overwrite older versions of PNDs? I usually don't connect my Pandora to the wifi much to download directly. Plus PNDStore detects the version number correctly via PXML regardless of PND name, right?


I would support some version numbers, like wesnoth-1.8.x for the stable version and wesnoth-1.9.x for the development version, but every new version of wesnoth-1.9.whatever would have the same PND name.

 

[milkshake]

yes PNDsotre does not care about the file name just the details contained within the PXML so if you update a PND it will remove the old one regardless of the file name and replace it with the new one.

 

[Mr Rob]

Well that's handy at least, though only handy for those that use PNDStore....

 

[milkshake]

PNDstore or panorama

 

[hmc]

when will panorama be available?

 

[DaMummy]

http://repo.openpandora.org/?page=detail&app=bzar-panorama


as far as when the next greatly improved update will be available, thats when its done. great thanks to B-ZaR and Cloudef for all work, as its looking absolutely wonderful and even so far, works great

 

[Cloudef]

I can add option for this in legacy libmilky and milkyhelper front-end.


(--keep-version?)


libpndman is still in the works and so far it's coming along quite nicely, Panorama will propably switch over that too when the time comes, as it is cross platform library and hopefully more stable.

 

[hmc]

http://repo.openpand...p=bzar-panorama


as far as when the next greatly improved update will be available, thats when its done. great thanks to B-ZaR and Cloudef for all work, as its looking absolutely wonderful and even so far, works great

Oops, I got it wrong then. I thought Panorama was the new "PNDstore" alternative with that great interface and functionality. I think I have seen a Youtube video about that.Probably Panorama is the UI used for that application...?Whats the application name then?Daniel

 

[F_Slim]

yes PNDsotre does not care about the file name just the details contained within the PXML so if you update a PND it will remove the old one regardless of the file name and replace it with the new one.

How are the application folders handled?


You might end up with a new one for each version, which takes up space (maybe unnoticed) or causes those "why the heck doesn't it find the game data, it's on there!" moments ... on the other hand, sometimes it might be useful to actually have different versions of the same software in parallel (maybe even with seperate application folders?)

 

[hmc]

as fasr as I know, the appfolder's folder name is determined by the application ID given int he PXML.xml file, so even if the PND file name is different and you use a newer version of the PND, it will use the same appdata folder as the older version.


So I see no problem here.


Daniel

 

[milkshake]

exactly if its an updated app the appid remains the same anyway, so the same folder would be used, but also you can specify the appdata folder to be different to the appid anyway using the pxml.

 

[WizardStan]

In the mid 90s, just as the web was first starting to stretch its newfound legs, a number of artists and photographers took to the medium to display their works. Long before photobucket, or deviant art, or whatever else they use these days, there was... actually I don't remember; this was 15 years, the particulars are a little fuzzy. I remember there was one website, whatever the name was, that would allow users to upload pictures they'd found particularly enchanting for whatever reason. This was a time when no one was making money off the internet so no one particularly cared who did what with the images, except one particular rant I recall. See, this was still the internet infancy, Web1.0 (or even 0.9, if you will) and a lot of mistakes were made, notably dumping all images into a single directory. Inevitably collisions occurred, and this was sorted by simply renaming the conflicting image. For reasons I never understood, this renaming, changing of "sunset.gif" to "sunset_1.gif" (for example) offended the artists far more than the blatant copying of their works. It was insisted that they had named it such intentionally and to rename it was disrespectful. This long winded anecdote is just one point in a long series which gave me the following insight: meta-data should never be stored in a container that the end user is able* to see and manipulate directly, especially if there are reasons that the end user may wish to manipulate that container, ie in the filename. If something is deemed broken because a user did something that they ordinarily have no problem doing (ie, renaming a really long PND filename to something shorter for easier reading comprehension perhaps) then that is a poor design.


*of course anyone with a hex editor is able to do pretty much anything they want with any meta-data stored within a file, but I am referring specifically to the stuff the OS lets and in many cases encourages them to do.

 

[Tempel]

libpndman is still in the works and so far it's coming along quite nicely, Panorama will propably switch over that too when the time comes, as it is cross platform library and hopefully more stable.

I hadn't heard about this! Do you have a source repository for it yet? I'd love to help with it; I've never written C before, but I know the syntax, and I certainly know my way around PNDs and repos. And I'm certain I've mentioned how much I'd like to retire PNDstore.

 

[Cloudef]

libpndman is still in the works and so far it's coming along quite nicely, Panorama will propably switch over that too when the time comes, as it is cross platform library and hopefully more stable.

I hadn't heard about this! Do you have a source repository for it yet? I'd love to help with it; I've never written C before, but I know the syntax, and I certainly know my way around PNDs and repos. And I'm certain I've mentioned how much I'd like to retire PNDstore.

[offtopic]


Sure, I'm atm going to holidays. But I'll put the current source @ git and inform you about it when I'm back


I'm lurking @ the irc most of the time, so it would be great + if you are around there.


The main reason for the rewrite is total redesign, as libmilky was born from totally different reasons than being a library. In fact I just forked pacman and included Jansson to read Repo JSON and make it handle PND's somehow. The resulted code is crap, but it "works".


The new code has more control over quality and currently compiles under Linux && Windows.. I would need a Mac to do the Mac part thought.


The design for it should allow simultaneous downloads, and the library would do little helping as possible to keep the library flexible for client application.


eg. from code view, you request handle from pndman, fill it with info and give operation flags, send it back to pndman and let it run.


pndman sends it back when error occurs or it was successful, and client then commits it to local database, when there are no other simultaneous commits going on.


But yeah, atm the code has uncomplete PXML parsing, and working device/mount detection and handling.


Edit: https://github.com/Cloudef/libpndman


I pushed it to git anyways.


If you want to help, just clone it and start hacking and send me patches so I can check and merge them if they are okay.


It would also be great if you can be @ IRC


Currently what it would need is libcurl backend code for JSON and PND fetches.


I can add more about the different parts and design somewhere in the git later.


[/offtopic]