[interfacekit] Re: BAppFileInfo test

Hi Erik,

Erik Jaesler <erik@xxxxxxxxxxxxxx> wrote:
> > I hope this doesn't sound rude as it's not meant this way. And in 
> > that
> > light, what do you think about it?
> No worries; you have never, in my experience, been anything less than 
> a
> model of diplomacy on these lists. =)

Okay, I'll try to keep it this way for now ;-)

> Honestly, I'm a bit torn on the issue.  On the one hand, slow fixes 
> on a
> core component are a serious bummer, and doing something to speed 
> that
> up is a good thing.  On the other, I put an awful lot of work into 
> the
> current design, and after having worked with it some recently, it's
> actually a much better situation than I initially thought.  I was 
> able
> to get back in the swing of it very quickly.  Considering the long
> stretch of time I've taken off between bouts of Haiku coding, I think
> that's saying something, even if it is my code. =)  So I think it's 
> not
> as impenetrable as it may look at first.  Also, this is a piece of 
> code
> that is basically complete, aside from bug fixes and very minor
> features; starting from scratch will be time consuming, when that 
> time

I just had a look at your code, too, and while I don't really think 
that it's a very useful application of the "template madness", I also 
don't think that it complicates things.

I am bit worried, though, about the flatten/unflatten code - it seems 
not only complicated, but also very slow; there is one copy of the data 
due to the design, and there is yet another one that I don't really 
understand (says to align the data in memory).
And while I honestly don't know enough about the 'FOB1' format, so I 
don't know if this could be done only a little bit better, or a whole 
lot :)
Which brings me to my next point: the flattening/unflattening code 
seems to be very static and hidden beyond several layers. While there 
is only FOB1 in R5, we may want to support either FOB2 or something 
self-made, too. Ingo and I also discussed the possibility of 
introducing a simple messaging system in the kernel that could be 
translated to a BMessage automatically (and probably vice-versa).
What I would have liked is a "native" format that don't need any copy 
or new when unflattening data. When I send a 1 MB message with the 
current implementation, it's not only very memory heavy, but also very 
slow. Messages are also often redirected or forwarded, and thrown away 
after a read-only usage - the implementation should reflect that. 
Another thing we should do is to use shared areas for messages above a 
certain size, and be able to work with those directly. too.
Do you have a good idea about that?
(of course, that's not the most important thing right now, it's more 
important to get it to work flawlessly, and the take care about these 
things)

> could be better spent elsewhere.  Yes, there is the semi-complete
> "other" code there, but it is a lot of "semi" and not very much
> "complete". =P

I didn't have a look at that code, but I guess that some refactoring of 
your code should be enough to meet the above mentioned points (note, 
that doesn't mean that you should get rid of the template madness, if 
you want to keep it :)).

> On a more personal note, BMessage is basically the last active
> connection I have to Haiku, and because of that, I am very loathe to 
> let
> it go.  That probably doesn't seem very fair, given the central role 
> of
> that code, but there you have it.  I know it's asking for a lot of
> patience, but if you'd all be kind enough to give me until, say,
> Christmas to either get the class's kinks ironed out or at least be
> acceptably responsive to issues, I would consider it a personal gift. 
> =)
>   If there's still unhappiness about the situation at that time, you 
> can
> do what you will to the code with my blessings. ;)  There's certainly
> plenty of other important work to be done in the mean time.

There is always plenty of stuff to be done, but it's always a problem 
when there is one component a lot of other things depend on. BMessage 
really plays a central role, so I would definitely argue that it would 
be nice to have more than one person that can work on it.
Having said that, I'm okay if you want to keep maintainership of 
BMessage, but it would probably nice to have a little more "overview" 
description in the source files, ie. a description of how it all 
connects. Just so that someone can fix a problem directly when it 
scratchs the surface.
Things like "what's the BDataBuffer class and why it's there", same for 
BMessageBody, a short comment on why Flatten()/Unflatten() should be 
implemented there, etc.
Being a maintainer of something doesn't mean one has to do all the work 
alone. It's a good thing to ease someone else into development as well.

Bye,
   Axel.

Other related posts: