Bryce -- us too
This is why I said 'all along' that I think we need to either extend PXML, or use a layer on top. We didn't have the manpower (ie: free time) to consider it well enough, and a few public discussions went all nuts, so we (or I?) simply just decided we'd leverage the community later for it. I do believe its better to start simple and gain traction for your niche target audience, then as you see where things are moving, you enhance.
So we all agree that adding to things is good; I think Torpor is going through same thought, but also wants to dump the whole .pnd thing entirely, whereas I'm interested in keeping the .pnd thing, but with a layer on top.
What I always figured was, during app discovery (on boot, or every once in awhile) could look up in Canonical Location for pnd-updates, and offer to or automatically download them. For my part, I think the base firmware should rarely or never loose a lib, we shoudl always just add additional versions or new libs, but never remove any (ie: to avoid risk to old apps.) So I always figured we'd have a repo for the firmware to push down fixes (where binary compatible) or enhancements etc, and then a repo (same one, or another one) for looking for pnd updates.
For pnd dependancies, sure, also; we either built some dependancies into PXML ("need this unique-id list to work", apply recursively), or better, we leverage some existing technology for that.
So I don't see using a repo manager as conflicting with PND-files, which is where I'm confused by all the above; a few people here or there seem to think we want peopel only downloading by hand, which of course is silly. (You can get files and maintain them however you want, ideally automated from a picker, or manually if you need/want.)
So I donm't think we're actually at odds, but people have some idea where they think we're going, and their idea vector is not actually where we're going; so they're fighting their perception of our target, not our real target.
Or maybe I'm totally wrong on lots of counts; thats always possible too
jeff
Bryce -- why would we do that? we designed it to handle that; we did not design around that, we designed tohandle it, should it happen; obviously multiuser is not likely, but multi-invocation is _very likely_. Consider -- what if someone makes a Firefox pnd, and then yoiu run two copies at the same time? Certainly not an unlikely scenario. In terms of full screen games, sure, but not for other apps. So we take things into consideration .. during designing and system, you figure the expected usage, plus some common other cases.. gotta try to be graceful in handling them, right?
BTW .. a unix system is multiuser nearly by definition, and many apps ported will expect it; certainly, you'll notice during first boot you picked a username (so we didn't just assume 'pandora', you get to pick a name.) But you could also create additional users and switch between them. What if you'r enot carrying it like a PDA, but using it as your kitchen computer with lots of users, or a guest account etc?