>> On 08/26/2012 04:55 PM, Timothy Pearson wrote: >>> Correct. You can blame various upstream system developers for that. >>> ;-) >>> >>> As an aside, if someone else would like to add a plugin to tie into >>> DBUS >>> for automount and such, I would be willing to work with them on the TDE >>> API side to make sure that the task can be accomplished. I just refuse >>> to >>> rely solely on projects which both use DBUS and are constantly being >>> replaced with a newer completely incompatible version. >>> >>> Tim >> >> What would it take to identify those upstream packages (a small >> reasonable >> list) that are critical to TDE function (the way you want it to >> function) >> and >> just bring that code over to prevent all of this incompatibility >> frustration. >> I know I feel it -- when it feels like the rug has been pulled out from >> underneath you -- by some whacky upstream change. > > Well, that is why I designed the TDE HW library to function on top of > procfs. Based on historical record, the chances of procfs disappearing > from the kernel are much, much smaller than the chances of a u* package > radically changing or becoming deprecated. > >> Following upstream is surely easier, but when you cannot count on them >> being >> there, that seems like a shaky foundation to build a house on... > > Precisely. > >> HAL, pmount, udisk, udisk2 is a good example of a constantly moving >> target >> where key functionality of TDE is at risk. > > Yes, I agreem. Note however that the pmount dependency is very small; TDE > only calls it as an external program, and the only thing that would break > if pmount were to disappear would be mounting of disk/media devices. > > As you look at the code I have written over the past year, you can see I > have been attempting to abstract all of these functions into a simple, > easy-to-use, standardized TDE API that new (or old) applications can use > to easily gain access to information that is normally very difficult to > retrieve. Another main function of this structure is to effectively > separate the (complex and prone to upstream breakage) backend code from > the user application code, obviating the need for full rewrites of TDE > applications code when upstream backends change. > > Tim Whoops, that should read "...rewrites of TDE application code when upstream backend libraries or daemons change". Tim