Pxml File Format Defintion

[yosh64]

hey

The primary goal of both PXML and .desktop is to point to stuff. They point to the file that should be run to start a program, the executable. They do a few other things, but that's their primary goal.

Dutch_Cap, I don't agree. I think the primary purpose is to privide information about a package, and a .desktop file alone cannot do this. I think the relative paths and such you mention is a non issue, this is something done by the GUI program.

Now, a .desktop file isn't meant to define information for a package, so it would be wrong to use it, or extend it for such purposes, but rather it's for (and I quote) "describing how a particular program is to be launched, how it appears in menus, etc". For example, there is no Software Version key for .desktop files, although there is a Version key for defining the Desktop Entry Specification it conforms to.

.desktop files point to executables with an absolute path. There's a good reason for this. It needs to be possible to move .desktop files around, so that I can put them in /home/Dutch_Cap/Desktop and get a nice icon on my desktop. .desktop files can use an absolute path because on most Linux systems programs don't move around much.

The design goals for PXML are slightly different, though. The directory that contains both the PXML file and the executable needs to be movable and it might disappear when you remove your SD card. However, the PXML file should not move relative to the executable. That's why PXML uses relative paths.

Actually, .desktop files usually contain a relative path, or rather just the name of the binary/executable without any path at all (this is because binaries of user applications are usually stored together in /usr/bin, and so this path is stored in the $PATH environment variable), although it's permitted by the .desktop standard to specify an absolute path, as I've already mentioned in a previous post.

Now, from what I understand no path is even specified within the PXML format (although it's optional to specify a relative directory to extract the ZIP to or whatever), rather the GUI application searches and gathers the directory of each package from the SDCard. I hope this makes some sense .

That said, as already stated in my last post, I also am +1 for PXML.

edit: I think EvilDragon somehow seen past all this and made/designed it the way it should have been from the start . I think most of our chitchat has been over our own misconceptions, but I dunno.

edit
Also, and unlike regular package formats, PXML not only provides information about the software, but information about how it's launched and appears in menus. I think this is where alot of confusion arises, as it blurs the line between the two purposes, and for reasons I mentioned in my last post I think it's better just to use PXML alone than to provide the package information along with the .desktop file.

I hope you take the time to read what I have to say , sorry if I overwhelm you with my big posts.

cyas

 

[Squidge]

yosh64: Don't forget that zip files are extracted into a directory for installation. So you have a directory on your sd card which contains both the app and the pxml file (in the same dir). The menu program just changes dir to this and runs the app from there. No need to do any extracting by the menu program itself.

It should also be very easy to create .desktop from pxml files - they will of course miss some information, but the resulting file should be useful for people not wanting to use the standard menu system with minimal (if any) hand editing.

 

[theoddbot]

I havn't fully thought this through yet, but adding some basic dependency management would be interesting. If a program needed say allegro as packaged by Joe, it could specify depends="joe.com/allegro" .

Libraries would also have their own pxml file stating what they provide, and a list of environment variables to chain up, so joe's allegro pxml would state something along the lines of:

provides="joe.com/allegro"
environment name="LD_LIBRARY_PATH" append="${DIR}/lib"

Any environment sections for a program's dependencies would be set up before the program is executed.

Something else that might be worth looking at is 0install http://0install.net/ which would handle downloading dependencies automatically.

Given that 99% of the running would be off SD cards, a system that is able to handle constantly changing filesystems would be required, not dpkg or rpm etc.

 

[Squidge]

I havn't fully thought this through yet, but adding some basic dependency management would be interesting. If a program needed say allegro as packaged by Joe, it could specify depends="joe.com/allegro" .

Wouldn't it be far easier for people just include allegro in the zipped package ? There could be a smaller archive for those people who know what they are doing (or know what they have installed).

That way you don't have people on the forums saying "Why won't this install ? It just mumbles something about a dependency failure. I'm confused. Help!". We can't assume auto-dependency management as they might not have Wifi.

 

[bzar]

I'd like to quickly state a few opinions:
1. The libraries needed by programs must go with the programs. This comes with the nature of having most apps on multiple removable storage devices.
2. Whatever launchers/package information files will be used, they must be movable, and move with the software. I for one don't want the gui to have all the programs I have on all of my sd-cards.
3. If .desktop isn't used, xml format isn't the only option. It's a good one in my opinion, but simpler yet extendable formats should be considered.
4. If a standard (.desktop, xml, deb) is followed, it should be followed to the letter. "Almost standard" is never good.
5. If a friend of mine has software on his/her sd-card, I should be able to just plug it in, see the programs on the menu and execute. No pandora-specific installation should be necessary.

 

[Squidge]

That is the general idea. If you remove an SD card, the programs on it will disappear from the menu. If you then re-insert it, the programs will re-appear.

 

[atomicthumbs]

I thought we were supposed to statically compile everything.

 

[Squidge]

I thought we were supposed to statically compile everything.

Statically compiling and including the libs in the same folder is kinda the same thing in my book. They both include everything required to run the app

 

[theoddbot]

I thought we were supposed to statically compile everything.

Statically compiling and including the libs in the same folder is kinda the same thing in my book. They both include everything required to run the app


So a 100kb pygame application should include 15mb of python interpreter and libraries?

I think there should be a way around this, though I agree the libraries should be included with the app in the general case.

 

[yosh64]

hey

I just wanted to mention that I agree with Dutch_Cap in the sense that PXML along with whatever GUI prog will mean that folks can easily dump things onto an SDCard and be ready to go.

Umm, I was thinking that I think an interface should still be made that simply scans an SDCard and gathers all package information and a directory map, it would save alot of hassle for other GUI developers and better promote the adoption of the standard.

That way, any GUI developers wouldn't have to fuss over using XML, nor would they have to worry about scanning through the SDCard(s) and extracting package information (especially from ZIP archives) and such. Contrary to what I said earlier, I would assume that PXML is supplied within the ZIP archive. Hmm, well from what I know (and I don't really know much about this, hehe) there seems to be no probs storing the package information within the TAR.GZ archive on Archlinux, so I think it might be the way to go.

I do agree with the design that using ZIP files and not TAR.GZ is the way to go, as they are more familiar and accessible to non Linux users.

edit
BTW, I think theoddbot makes a nice point, I do think there should be the option to dynamically link or whatever. So would that mean a Linux file structure/layout or whatever would be needed to be setup on the SDCard? I mean a directory layout alike /usr, /usr/share, /etc, or whatever it is that's needed.

cyas

 

[Squidge]

So a 100kb pygame application should include 15mb of python interpreter and libraries?

Yes, as thats the only way your going to be sure that anyone can just download that app and have it running without moaning about missing files.

There's nothing stopping them doing another version which is 15MB smaller for the more advanced people however. If it doesn't work for them, they can always just download the full version and get the prog working without getting frustrated.

all package information and a directory map, it would save alot of hassle for other GUI developers and better promote the adoption of the standard.

Yes, I agree. It could probably ship with a library of some sort which does all the usual stuff for you. Maybe even have it as a dyn lib in the OS, so it can be updated without having to rebuild the stuff depending on it.

The idea with .ZIP is so non-Linux people can easily extract the archives direct to SD cards if they wish. I know there are tools for stuff like .tar.gz on Windows/etc, but zip is far more popular, understood more, and is even built-into some OSs.

 

[Dutch_Cap]

The primary goal of both PXML and .desktop is to point to stuff. They point to the file that should be run to start a program, the executable. They do a few other things, but that's their primary goal.

Dutch_Cap, I don't agree. I think the primary purpose is to privide information about a package, and a .desktop file alone cannot do this. I think the relative paths and such you mention is a non issue, this is something done by the GUI program.
I think it's a very clear incompatibility between PXML and .desktop. The GUI needs a path to an executable to run the program. .desktop cannot provide this path in such a way that you can move the program around.

Now, a .desktop file isn't meant to define information for a package, so it would be wrong to use it, or extend it for such purposes, but rather it's for (and I quote) "describing how a particular program is to be launched, how it appears in menus, etc". For example, there is no Software Version key for .desktop files, although there is a Version key for defining the Desktop Entry Specification it conforms to.

That might be an even better reason not to use .desktop than mine...

.desktop files point to executables with an absolute path. There's a good reason for this. It needs to be possible to move .desktop files around, so that I can put them in /home/Dutch_Cap/Desktop and get a nice icon on my desktop. .desktop files can use an absolute path because on most Linux systems programs don't move around much.

The design goals for PXML are slightly different, though. The directory that contains both the PXML file and the executable needs to be movable and it might disappear when you remove your SD card. However, the PXML file should not move relative to the executable. That's why PXML uses relative paths.

Actually, .desktop files usually contain a relative path, or rather just the name of the binary/executable without any path at all (this is because binaries of user applications are usually stored together in /usr/bin, and so this path is stored in the $PATH environment variable), although it's permitted by the .desktop standard to specify an absolute path, as I've already mentioned in a previous post.
You're right of course, though I wouldn't call an executable name a "relative path". (I didn't mention this because I wanted to keep things simple and not go into the PATH environment variable and such) However, this means the directory containing the executable needs to be detected and added to the path somehow. It doesn't really solve the problem because it creates an identical one.

Now, from what I understand no path is even specified within the PXML format (although it's optional to specify a relative directory to extract the ZIP to or whatever), rather the GUI application searches and gathers the directory of each package from the SDCard. I hope this makes some sense .

To quote the current PXML definition: <exec></exec>: The name of the executable to be started (path relative to this XML)

That said, as already stated in my last post, I also am +1 for PXML.

edit: I think EvilDragon somehow seen past all this and made/designed it the way it should have been from the start . I think most of our chitchat has been over our own misconceptions, but I dunno.

I know, I'm just trying to help everybody catch up.

edit
Also, and unlike regular package formats, PXML not only provides information about the software, but information about how it's launched and appears in menus. I think this is where alot of confusion arises, as it blurs the line between the two purposes, and for reasons I mentioned in my last post I think it's better just to use PXML alone than to provide the package information along with the .desktop file.

I hope you take the time to read what I have to say , sorry if I overwhelm you with my big posts.

Big posts do have some advantages over the short cryptic ones I tend to write.

 

[nugl]

I think XML is too complicated to for this
the .desktop spec is OK but doesn't exactly fit.
so why not create something simple/new?
with a skeleton someone new will fastly grok the format
maybe even faster than a XML spec.

example game.pan
CODE

name: SmashBill
version: 1.2.34
icon: pics/smashbill.png
exec: smashbill
standalone: y
background: y
category: egoshooter
filetype: game/smashbill-map::game/smashbill-serverconfig
compresspath: maps
clockspeed: 600
osversion: >=1.7.1::<1.9
preview: pics/screen1.png:ics/screen2.png
short.en: short description of the program in english
short.de: Kurze Programmbeschreibung in Deutsch
long.en:
long description of the program in english.
URLs are parsed and selectable in the GUI.
http://smashbill.sf.net
http://smashbill.net/board/
mailinglist: mailto:smashbill-devel@lists.sourceforge.net
maps: ftp://smashbill.net/maps
long.de:
Lange Programmbeschreibung in Deutsch.
URLs werden analysiert und sind in der GUI anwaehlbar.
http://smashbill.sf.net
http://smashbill.net/board/
mailinglist: mailto:smashbill-devel@lists.sourceforge.net
maps: ftp://smashbill.net/maps

 

[sebt3]

example game.pan
CODE

...snip....

This look like debian control file. And just saying this I'll go for XML

edit: I Just wanted to add that ED said in the blog that an update to the pxml format will be posted soon. So he is going for XML which is not a bad thing after all.

 

[Squidge]

I think XML is too complicated to for this
the .desktop spec is OK but doesn't exactly fit.
so why not create something simple/new?

Because typically thats more complicated than using XML. Remember that XML libraries are in there dozens. If you create your own format, you have to create all the libraries from scratch.

Eg. What is so complicated about something like:

XNode xml, el;
xml.Load ("foo.pxml");
if (el = xml.Find("exec")) Exec (el.Value);

 

[dentrado]

I think XML is too complicated to for this
the .desktop spec is OK but doesn't exactly fit.
so why not create something simple/new?

Because typically thats more complicated than using XML. Remember that XML libraries are in there dozens. If you create your own format, you have to create all the libraries from scratch.

Eg. What is so complicated about something like:

XNode xml, el;
xml.Load ("foo.pxml");
if (el = xml.Find("exec")) Exec (el.Value);


How about YAML then? Then you don't have to invent something completely new and still it's easier to read.

 

[multiplex]

Eg. What is so complicated about something like:

XNode xml, el;
xml.Load ("foo.pxml");
if (el = xml.Find("exec")) Exec (el.Value);

That's horrible, though. <_<
You're just picking the first exec element you find, which could very well be part of third-party data.

In fact, here it looks like you're using it for a simple key-value mapping, for which I'd say XML is neither particularly well-suited nor easy to use.

 

[sindbad]

This just dawned on me. Why not JSON?

 

[Squidge]

How about YAML then? Then you don't have to invent something completely new and still it's easier to read.
Yes, it's easier to read, but it's not as self-descriptive as XML unless you read the documentation. With pxml, the idea is that you can throw the pxml at a browser like Firefox and it'll decode the contents for you. No parsing required.

That's horrible, though. <_<
You're just picking the first exec element you find, which could very well be part of third-party data.

In fact, here it looks like you're using it for a simple key-value mapping, for which I'd say XML is neither particularly well-suited nor easy to use.
It was meant as an illustration of its ease of use to developers, it's not meant as a full blown example of how to retrieve the 'exec' element.

 

[CiderPunk]

my god! I've been reading this thread for a while now and i can't stand by and idly watch any longer!

XML is the way forwards!

XML is ridiculously easy to edit by hand. its like writing html, you remember html? you just have to remember to match every tag with a corresponding close tag and even then it's not like its the end of the world if you miss one, 'cos any parser worth its salt will quickly tell you what you missed and even which line its on! it's not like your writing huge documents here anyway!!?!?

XML provides massive flexibility, unlimited extensibility, you can edit them in any OS without worrying about which linefeeds or carriage returns your text editor is using.

There's a reason the whole worlds using XML, welcome to the future! don't be scared!