[interfacekit] [openbeosstorage] BMimeType discoveries

Hi,

just recently I sent a mail to the SK team list that is related to the
regristrar discussion, thus here it comes again...

8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 

Hi,

I played around with the R5 BMimeType implementation and want to share my
new insights:

* The Get*() methods directly access the MIME database.

* The Set*() methods send a message to another entity which does the job.
  The function that does the sending is called _send_to_roster_(), so I
  suppose the roster is the one. Since the registrar has a thread named
  _roster_thread_, I assume the roster lives in the registrar.

* Start/StopWatching() call BRoster::_Start/_StopWatching().

* Adding/removing a MIME type file in ~/config/settings/beos_mime/*/ does
  not trigger a notification message. So obviously no node monitoring is
  done and changes to the database are supposed to be done using the API.

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.

Maybe some more information about roster, app server and registrar and
friends might make decisions easier.

CU, Ingo

8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 

Well, the last mail from darkwyrm lists the registrar's task. I still
only have a vague understanding of how it works together with the app
server and API classes like BApplication.

But all that is actually not that important as we are not bound to Be's
design and have the freedom to arrange things like we please.

CU, Ingo

Other related posts: