Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosstorage] || [Date Prev] [06-2002 Date Index] [Date Next] || [Thread Prev] [06-2002 Thread Index] [Thread Next]

[openbeosstorage] Re: BMimeType

  • From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Thu, 06 Jun 2002 22:26:49 -0700

> > As the quarter's winding down and I'm starting to have some free time
> > again, I think I'll begin working on BMimeType if no one has any
> > objections.
> 
> Arrghh, I was apparently too slow. ;-)

If you hadn't slacked off so much... :-)

> I hope you start with the documentation and the tests. I would be really
> sad, if only these annoying tests would be left when I join you. ;-)

Send me a list of the pieces you want me leave for you, and I'll see what I 
can do. :-P

> > I played around with it a bit today. The MIME string stuff shouldn't be
> > hard. The MIME database stuff looks pretty straightforward. I think the
> > sniffer rule stuff should be mostly straightforward as well. The MIME
> > monitor functions I'm a little unsure of; I imagine one could implement
> > that with a node monitor for every file in the database, but I'm wondering
> > if it could be done more efficiently. We shall see...
> 
> A lot of functionality should be implemented using the registrar. The MIME
> monitoring for sure, but also most of the other things.
> I would like to avoid to access the MIME database directly from the BQuery
> code, but rather let the registrar be the only one manipulating and
> reading the database. This avoids locking problems, problems with
> monitoring -- we can't monitor each single mime type -- and may even
> improve performance, since the registrar may cache some (or even all)
> data.

Very, very good points.

> However, we will have to write a registrar, since I doubt that the IK team
> will provide it for us in the near future. Before doing that we should
> negotiate a couple of things with the IK team to avoid, that our work is
> for the trashcan. At least the communication protocol should be worked
> out. Then, if necessary, the whole registrar can be replaced without
> touching the BMimeType code at all.

Yes. I'll get in touch with Erik.

> As you may have seen, I commited the BQuery test suite. Live query
> tests are still to be done, but that shouldn't be too much work. So one
> (longer) session should be enough to finish BQuery. I anticipate a
> successful weekend. :-)

Good to hear :-)

> We should agree on how to distribute the work.
> E.g. I wouldn't mind not to touch the class itself -- avoiding to disturb
> you -- but rather start with the registrar.
> What do you think?

Damn. I was looking forward to doing the MIME database stuff. :-) But that's 
probably a good idea. Let's do that for now at least, until we get the 
general shell implementations done. After that it might make sense to split 
it up by functionality (database/sniffer/monitor) so the same person is 
working on both ends of the communication pipe. What do you think?

-Tyler





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.