[interfacekit] Re: BMimeType discoveries

My 0.02 credits on something:
<..>
>I too like the idea of having all the Get*() and Set*() functionality 
>implemented in one place, along with a cache in the registrar.

Not sure about this, whether it's a matter of caching; according
to what you & others have posted, and whatever i know of the OS,
I suspect this all has to do with serialization:

BMimeType::Get* is done directly to disk because well, concurrent
reading's can be done at the same time, but Set* calls have
absolutely to be serialized if they happen to be performed
on the same MIME type -- which boils down to "on the same file in
/boot/home/config/mime...".

I even wonder about Get* being performed direct-from-disk,
what if a *write* occurs at this very moment? Or maybe
BNode::Lock() is used to prevent any attribute reading until
the WriteAttr() is complete?

It seems we have at least half the answers, if not most... anyway
as someone said, even if we don't replicate the exact implementation,
what is important is we know the *feature-set* (and reliability)
we want to replicate. Concurrency is one of the constraints you
guys should have in mind I guess.


> I'm not the 
>most educated on the topic, but messages are fairly cheap, aren't they? 


As long as it's not the bottleneck (only the case for graphics
drawing, far as I know), messaging should be done with the
most voluptious class known to the IT world, definitely agree :-)
(voluptuous (ps) and relatively cheap, indeed).


>Seems to me we could do it that way (unify Get*() and Set*() in the 
>registrar), and if we weren't happy with it, move the code for the 
Get*() 
>functions into BMimeType and scrap the cache in the registrar. In fact, 
we 
>might as well just do the registrar uncached to begin with, and add 
caching 
>later if we decide to stick with the unified route. 
>
>As to monitoring, that would continue to be dependent upon access 
through 
>the registrar,

Node Monitoring will give you consistency (implement the "Observer"
pattern) but not serialization/safe concurrency.


> due caching (i.e. modifying the database manually would not 
>trigger updates). That seems reasonable to me, as I can't think off 
hand of 
>any good justification for not going through BMimeType.
>
>What'd'ya think? 

Keep it up guys; glad to see talks starting about the registrar,
it'd be a shame to manage to compile the deskbar in a few months
and have the BRoster class never return any GetAppEntryAt() !

--
PGP key: http://cdegea.free.fr/degea_kagi_pubkey.txt | BeDev E-16870
"What's oil got to do, got to do with it" -- F02 Chorus

Other related posts: