Pxml File Format Defintion

[yosh64]

hey

I was just thinking, the nice thing about XML and such is that I think it is very logical and strait forward to write. As was already said, you just put things between tags, and this concept of this is very well known.

My only concern is the speed of parsing and such, but this probably isn't an issue, and I think the pros far outweigh the cons.

As was already mentioned, as it's already so well supported the information from all the packages could more easily be presented on the web.

cyas

 

[cosam]

Whichever way it goes, I'd like to see some kind of "run in terminal" option so that command line programs can be launched from the GUI. Or is this catered for in some other way?

 

[AireTamStorm]

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.
There is, its called package mangement. If your Pandora doesn't have the required libraries, they are downloaded from a repository automatically. Its the same with pretty much every Linux distro on the planet, I do not see the problem with using in on a handheld that is trying to do alot of the same things. I'd hate to have 30 copies of Python on an SD card just to maintain the current "drag and drop" headache.

Edit: If Squidge is talking about zipping up a .deb in with a game, thats a different story altogether.

 

[multiplex]

t 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.

Yes, but when you're parsing it properly, it's not as easy to use anymore.

Sure, there are a lot of stuff like XPath that makes complex stuff like extracting info from HTML pages and searching hierarchies and stuff a snap, but that's a significant overhead when you're parsing a lot of small files, and the best you can hope for is to match the ease of use a simpler format.

Not saying anything about PXML in particular, but IMHO XML has a somewhat undeserved reputation of being easy to parse and in general having some kind of 'goodness' about it that makes people use it when they'd probably be just as well off without it. A custom XML format isn't much easier to read than any other well documented format, you don't get any magical interoperability by using it, and if you aren't representing nested hierarchial data or using weird encodings (these days, anything not utf-8), all you get out of it is the wide availability of trivial tokenizers.

PXML will do just fine, but I don't think XML offers any particular advantage in expressiveness or ease of use here.

 

[bzar]

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.
There is, its called package mangement. If your Pandora doesn't have the required libraries, they are downloaded from a repository automatically. Its the same with pretty much every Linux distro on the planet, I do not see the problem with using in on a handheld that is trying to do alot of the same things. I'd hate to have 30 copies of Python on an SD card just to maintain the current "drag and drop" headache.

Edit: If Squidge is talking about zipping up a .deb in with a game, thats a different story altogether.

IMO the biggest problem in package management for pandora is that most of the disk space is removable storage. The internal flash of pandora can only hold so much, and having packages installed on sd cards would bring a lot larger headaches.

For instance, if your package manager checks the existence of, say, an arbituary python library and finds that it's installed, it sees everything as ok, when in reality the library is installed on another sd card. Any package management would have to be sd card specific, so that the package information would be on the sd card. Hmm...

 

[cosam]

IMO the biggest problem in package management for pandora is that most of the disk space is removable storage. The internal flash of pandora can only hold so much, and having packages installed on sd cards would bring a lot larger headaches.

For instance, if your package manager checks the existence of, say, an arbituary python library and finds that it's installed, it sees everything as ok, when in reality the library is installed on another sd card. Any package management would have to be sd card specific, so that the package information would be on the sd card. Hmm...

Yep, removable storage is the challenge. I don't know of any package managers that handle this well, probably because most are designed around fixed storage. It could however be doable if the package manager's database also included some identifier from which you could derive which SD card(s) package X or library Y was installed. It would be possible to check which resources are required when a program is launched (probably through some kind of wrapper) and prompt for the relevant SD card(s). It could even be possible to detect when dependencies were spread over > 2 cards and tell you which packages could be moved or copied. For that matter, it could even do the copying for you.

I'm not saying it'd be easy. It probably also wouldn't scale well to large numbers of cards, but I'm guessing that with today's high capacity cards, most users won't have all that many as to make such a system impractical. If there's support/demand for such a system, and assuming no-one's already working on one, I would gladly bash out a preliminary design for it.

 

[Squidge]

If Squidge is talking about zipping up a .deb in with a game, thats a different story altogether.
No. The .zip file contains the application, app data, and pxml file. Nothing else. No repo info, no package info. If an app needs external libraries to work, they will be packaged in the zip file for ease of installation (and most people will no doubt also create a smaller version for the people who are more familiar with Linux, but they'll have to manage the libraries themselves).

 

[basicmark]

Personally I don't see the point of reinventing the wheel, there are already lots of package management systems you there, why create another?

A couple of questions on what has been proposed so far:

"Apps extracted anywhere and run". How are you going to handle dynamic libraries? Some how you need to convince the dynamic library loader to pick up your lib which, if you can untar anywhere, will most likely not be in the standard search path. I know you can get add new directory's to the ld search path (ldconfig -p?) but I think that would add it to the ld cache which you probably don't want to do. I guess that LD_LIBRARY_PATH would work but this would have to be setup by some kind of launcher.

It seems that I end up with the same library(s) many times wasting SD card space and just generally doesn't feel like a good idea.


0install looks interesting, I might have to look how it works under the hood .

As for running applications from other sources then I would have thought that ipkg would be a good idea and is targeted at embedded systems. It's supported under OE which would give you access to over 3000 other packages .

 

[Squidge]

Personally I don't see the point of reinventing the wheel, there are already lots of package management systems you there, why create another?

PXML isn't a package management system. It's simply information about the archive.

"Apps extracted anywhere and run". How are you going to handle dynamic libraries? Some how you need to

Typically, the only dynamic libraries will be the ones pre-installed to nand. Others will be statically linked to the executable, unless the library is large.

I guess that LD_LIBRARY_PATH would work but this would have to be setup by some kind of launcher.

Which the device will have Everything will run from the laucher, which will include the current directory into the LD_LIBRARY_PATH.

Of course, if your a Linux guru, you can modify to suit, have a library dir on your sd's, etc. The above is meant to be simple and easy to use for people who have never used Linux, and those who want to manage there cards from Windows. After all, space is cheap these days

 

[yosh64]

hey

Ya know, I dunno if it's very wise to ignore, or dismiss the issue of dynamic linking all together or whatever. I think there will be people who will probably use it, which might lead to a number of different ways of doing things and make it hard for people unfamiliar with Linux to figure things out. So why not define a standard directory for placing dynamic libraries and such things on the SDCard?

I was thinking for things like Ubunto or whatever Linux distros that they would just setup a regular Linux filesystem on the SDCard, rather than anything specific for the Pandora. Hmm, well this seems most logical to me, and might be what I do myself if I try to install some Linux distro or whatever. So how will people go about having a regular Linux distro and filesystem with PXML and such? I mean, I think there needs to be a utility with PXML to install packages to a regular Linux filesystem, and generate a .desktop file for use with whatever Window Managers.

Anyhows just something to think about.

edit
I guess you could just make a package for PXML for whatever Linux distro, and then just run whatever PXML based GUI prog to browse and launch whatever PXML software packages. But, there might be issues if the GUI prog or whatever is also a Window Manager and such. Also, some folks might not like having to use the GUI prog within whatever Linux desktop environment.

cyas

 

[multiplex]

Thinking a bit about the launcher vs. package distinction issue...
I don't see any provision for having multiple launch targets in a single package? It's rare, but it happens, e.g. for an office suite. When people are are already edgy about non-shared libraries, having to make multiple packages with nearly the same files just to run different targets seems a bit much. Having multiple PXML files share the same files sounds like it'd severely confuse the auto-update package management proposed so far.

Extreme example: Needing 6 identical copies of OpenOffice.org to run Writer, Calc, Impress, Base, Draw and Math. :blink:

 

[sindbad]

Thinking a bit about the launcher vs. package distinction issue...
I don't see any provision for having multiple launch targets in a single package? It's rare, but it happens, e.g. for an office suite. When people are are already edgy about non-shared libraries, having to make multiple packages with nearly the same files just to run different targets seems a bit much. Having multiple PXML files share the same files sounds like it'd severely confuse the auto-update package management proposed so far.

Extreme example: Needing 6 identical copies of OpenOffice.org to run Writer, Calc, Impress, Base, Draw and Math. :blink:

Very good point. This could be done with multiple .desktop files.

I'm more and more leaning towards having pxml files and .desktop files generated for the launcher, either by the developer or when the apps are discovered.