On Mon, 29 Aug 2011, Jari Vetoniemi wrote:
# heck there should not be even reason why the disco struct would not # give all the information from PND.
It wasn't done at random; best to consisder a projects history when putting code in (just like its a best practice to make new code fit existing code in style to avoid having 30 peoples fingerprints all over it, its usually good idea to find out why something is the way it is.) Just as a typical container class doesn't expose the inner workings of the structure unless you ask to see it .. the user often doesn't need to see it all unless they want to.
Permit me to meander, it may be useful to be on record so readers down the road know why things are the way they are.
But I might have been wrong there with disco-t and pxml-t, who knows; recall that when this stuff was designed, we were already past 'release date' and thought we had only weeks to build the entire thing :)
The reason I did that (perhaps unwisely? who knows ;) was that the PXML could include a 'lot' of stuff, and certainly stuff 'light users' (such as launcher menus) may not want to know about (witness, packages and so on. At the time, I was thinking about long descroptions versus short descroiptions and multi-language .. I figured that if disco was in (say) English context, and quite possible apps might have dozens of length descriptions in many languages and we are on a constrained device, it best not to return all of them, say.) I had rather figured two interfaces that you can see..
- discovery -- find apps, and report 'minimal' info (which is now a lot of info, but originalyl ewas just a half dozen fields); consider minimenu or even a simpler menus -- use cases are.. . get me a list of apps (or scan one app) . run an app ... doesn't care about icons or packages, etc
- pxml-parser -- given a discovery return, if you want more info, go ask pxml parser to get you the full details for a given app(s); it had been intended that to keep speed up, this would be cached, but I never got so far as to release any caching code for discovery or PXML, so fetching each PXML is slow still due to the mount/pull/unmount problem (something else we wanted to address :) Use case was.. . get me a list of apps (or scan one app) . want more? pull the pxml (slow, or cached, internally by libpnd) . do something (show it, run it..) . remember, to get icon or the like, it also has a mount, so its not so far fetched to then parse the PXML then. Minimenu does its own caching, for instance, too.
So the goal was separation -- light pull, versus comprehensive per unit pull; instead, now we've got a lot of the data in disco-t (to save on extra PXML pulls), which means we have disco-t and pxml-t with multiple get/setter type functions, data copying and so on. Right now disco-t still doesn't have all the multilanguage stuff and all that, but we're rather leaning that way it seems, which may or may not be wise, who knows.
To me, it seems like.. if we're going the route of disco-t being a clone of pxml-t, maybe the two handles should be the same thing, so one set of getter/setters... or we go back to the way it was originally intended. ie:Whats the point of articulation here -- get it all in one swoop, or get a little bit and pull as needed; whats are usual use case, so we can best serve it?
(Who is the audience for libpnd? So far it is things like minimenu, pndnotifyd, milky and pndstore .. the libpandora type stuff for IO/cpu-setting/etc is really considered separate.)
If we look at libpnds audience as tools like that, pretty low level stuff, that maybe pushes us towards the all-in-one-swoop mentality; at the time, libpnd/libpandora were thought of as being more linked to a lot of apps to make dev porting easier (just use the ready to go IO stuff, say) so I wanted to keep it mroe general, hence the leaning towards the quick swoop and pull detail later.
Hindsight always lets you review your guesses :)
Rigth now we're sort of in the middle.
But thats okay -- evolution happens, and being pragmatic, we use what works and try to aim for the best. Truly clean code only happens in textbooks ;)
# But yeah, I'll lurk around and see what future holds.
Well, you're making it, so hope so :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.