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