[interfacekit] Re: BMimeType discoveries

> > This leads to the question, what we want to implement similarly and 
> > what
> > differently.
> > I wouldn't like to implement the actual Get*() and Set*() 
> > functionality in
> > different places, though it might make sense for performance 
> > reasons. I
> > suppose most of the database accesses are read only, and the 
> > overhead of
> > additionally sending a message forth and back might be considerable 
> > big.
> > On the other hand there are certainly only a few MIME types that 
> > are
> > usually used, so caching implemented in the registrar would mostly 
> > avoid
> > file accesses.
> 
> I too like the idea of having all the Get*() and Set*() functionality 
> implemented in one place, along with a cache in the registrar. I'm 
> not the 
> most educated on the topic, but messages are fairly cheap, aren't 
> they=3F 

Hopefully. For (potentially) large Mails, e.g. those sent by Get/
SetIcon(), GetInstalledTypes() and others, a solution using areas might 
be considered. It might get a bit messy though.

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

That sounds good to me.

> As to monitoring, that would continue to be dependent upon access 
> through 
> the registrar, 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.

Agreed. BTW, actually I don't see any reason why the register shouldn't 
do node monitoring at least on the supertype directories. But that 
doesn't have priority.

CU, Ingo

Other related posts: