And since all the chatter is in IRC ..
Try to keep it on list ;)
- .desktop files could replace PXML for sure; someone needs to itemize the value of PXML and compare to .desktop and see if .desktop can do it all, and if so, we could switch. We moved fast last time (we thought pandoras were shipping like 6 weeks later :), so I think we latched onto PXML quickly and just stuck with it. We also liked the idea of XML validators, etc, but we all know XML makes baby jesus cry.
- zip appending could be cute; would be uncompressed probably, since we're not worried about the compression (most stuff in the appdned bits are small, or uncompressible anyway, like audio clips or pics.) We're concerned about speed of locating, and the index, that a zip would provide .. faster access to _find and pull_ stuff. Nothing to do with runtime performance.. pnds already perform pretty well. App discovery and pulling PXLM and icons, thats slow.
- appending tar is no better than what we have now since it has no tail-index :)
Now, keep it on list :)
jeff
On Fri, 25 Feb 2011, Jeff Mitchell wrote:
# # Re-targeting the list. # # ---------- Forwarded message ---------- # From: Jeff Mitchell skeezix@skeleton.org # To: "[ISO-8859-1] S�bastien Huss" sebastien.huss@gmail.com # # On Fri, 25 Feb 2011, [ISO-8859-1] S�bastien Huss wrote: # # # The nice thing of having the filesystem at first and the rest appended at # # the end is that the filesystem is immediatly available to be mounted : no # # need to do ugly hack to have mount to see the filesystem # # Actually the loopback mechanism (these days, not years ago) can # usually take an offset, so you canhave a binheader and not too much work # .. as long as calculating where the filesystem is is easy :) # # # > - payload filesystem change; # # Might be nice, but does zipfs support Unix like priviledge-system ? # # Support enough I think; I doubt pnd_run.sh itself cares about the # appended parts, just the main payload; but libpnd cares about the appended # stuff, and its easy to read a basic zip, without mounting zipfs. # # I've often thought it would be cute to do iso+zip, with the zip # part having one PXML.xml or the .desktops, and icon(s), and anything the # dev wants to publish easily (audio clip or screenshots.) # # # > - appended format; # # That sound like the simplest, yet best solution so far. No change to # # pnd_run.sh, only adding the previews and the icons there. sdound resonable # # for me and will fixes thoses little limitation we have currently # # It'd be easy to add to libpnd. # # In fact, I added iso/squash/whatever+zip in a couple of times a # year ago, its very easy. # # Folks in IRC tended to dislike the idea though, so its not in # place, but it could be. # # atc -- your time to speak up! # # # > - theres 'crazy like a fox' ideas too; # # > # # the thing I like here is that you could then have a modified bitbake to # # build pnd more easily than with current situation. But all these overlay is # # the best way to shoot into your feet imho. (once you start 2 apps and # # more...) # # You could just use debian packages at this point too, or other # crazy tricks; but having 300 overlays is just not going to work imho :) # # Still, floor is open for other ideas; I admit, I'm ovrworked and # fried in the end, so really outrageous creative solutions aren't coming to # mind for this .. so its very possible some truly awesome idea is out # there. # # But that side, the conventional ideas I think I listed there. # # So I'm a bit of a fan of iso(whatever)+zip, but I've also not # actually run down the pros/cons yet to see if its a worthy addition. # # filesystem + zip-appended # # Pro: # - doesn't fight with current system # - trivial to add with no user confusion # - improve performance of some operations, with changes to libpnd # to understand it; ie: fast fetch of screenshots # # Cons: # - still goofy filesystem plus something, which I don't personally # mind # # Before we consider acting on that, best to consider all the # options, and pick the best overall one. Just adding this one would end up # with two systems, and then if we find a better, we'd have 3 ... better to # let it sit, and find a better solution, and go to that. # # I also like libpnd nice and simple, so we can hack on it and # grow/change it easily, with little baggage; keeping it simple makes for # speedier adoption by developers, reliability makes it adoptable by users. # Complexity is bad for both scenarios. # # So libpnd hasn't changed pnd-files since inception a year or two # back, but thats okay. We want adoption. # # But nows a good time to figure out if there is changes to be. # # jeff # # # -- # If everyone would put barbecue sauce on their food, there would be no war. # # !DSPAM:4d680190334175616312847! #
-- If everyone would put barbecue sauce on their food, there would be no war.