[interfacekit] Re: input_server and registrar

On Tue, 17 Jun 2003 14:00:38 +0200 "Marc Flerackers" <
mflerackers@xxxxxxxxxx> wrote:
> 
> > burton666 <burton666@xxxxxxxxx> wrote:
> > > It could be useful to test it with a working base, to begin with.
> > > Moreover, we could > even release a replacement for R5.
> > > Anyway, I guess the input server/app server are more important, 
> > > and
> > > we could even > replace them on the existing R5 installations. 
> > > Wasn't
> > "replace R5 piece by piece" the > motto of OpenBeOS ? :=)
> >
> > I don't think we should do that - it seems to be much work with 
> > very
> > little gain to me.
> > I also think those who follow this project have understood that we
> > won't replace R5 piece by piece for those things - and so much work
> > just for a PR gag...
> 
> I don't know how long it takes. At least for the input_server it took 
> me
> less then an hour to write the libbe functions which communicate with 
> the R5
> input_server, and they work. The OpenBeOS input_server just needs to 
> respond
> to these messages (a question of changing the message id's and 
> message field
> names), to work with the R5 libbe.
> 
> And it's not just for PR. Doing it this way, the input_server could 
> be
> tested in a working environment. And completely tested and debugged 
> before
> the other components are ready. Also performance can be compared.
> The other way you would wait for app_server/input_server/registrar/
> libbe to
> be finished, and then hope each one works, and works well together.

I don't know about the input server, but the registrar is virtually 
complete (only shutdown functionality is missing and background MIME 
sniffing). The relevant parts of all associated classes are implemented 
and have a reasonably exhaustive set of unit tests, that were all 
passed the last time I checked. There certainly remains some 
integration testing to be done, but I wouldn't see, how integrating it 
with R5 components would help us in this respect. Regarding 
performance, I think, there's very little that we might possibly have 
been screwed up. There are a couple of structures in the registrar that 
are marked to be reviewed for performance issues, but that shall be 
done, when it makes sense.

As for the time the adaption to R5's protocols would take, I'm very 
sure, that I couldn't do that in an hour. I suspect alone adjusting the 
800+ lines of protocol specification (docs/develop/servers/regstrar/
Protocols) would take me that long. And, as I wrote earlier, we don't 
implement the complete protocol of the R5 registrar, nor would I 
believe, that the part we have implemented is semantically equal (I'm 
actually sure it isn't, for we deviated on purpose in some respects). 
So, I believe, that task would comprise a considerable amount of work 
(several hours at least), while I don't see any (significant) 
advantages. We even had to take back some design decisions we made 
purposefully, which I'd consider a drawback.

CU, Ingo

Other related posts: