[interfacekit] Re: PortThief

>Why?  We control app_server *and* the IK/App kits -- the protocol is 
>whatever we choose to make it!  We're no longer operating under the 
>assumption that we can drop app_server in by itself; reverse engineering 
>the protocols will take far more time than it's worth.  As far as I'm 
>concerned, any apps out there that communicate directly with app_server 
>via those protocols were written by psychotics. ;)  I'm not worried 
>about supporting any app that isn't using app_server via the kits, which 
>constitute app_server's public API.  Be has apparently changed this 
>protocol -- sometimes a little, sometimes a lot -- with nearly every 
>release of BeOS.
Oh, DUH! <smacks forehead> I forgot that we're not just dropping in the 
app_server, but *also* libbe.so  and the input server. In a perfect world, 
we'd be able to drop in any one of those three and have things work the same 
way. Reversing the protocol will take a lot of time, so I'll probably be 
asking you guys about what you think the protocol should be as I get working 
on it.

>Maybe I'm not following you here -- it (basically) sounds like you're 
>saying each BView has a client-side bitmap that it draws on and which 
>the app_server blits to the frame buffer.  Am I understanding you 
>correctly?
Yep.

>Now I'm confused (only just now, you ask? ;).  I can definitively say 
>that all drawing is done in the app_server -- each BView drawing method 
>essentially marshalls its parameters and sends them to app_server, which 
>does the actual drawing.  The interface kit basically acts as a proxy 
>for the app_server; AtheOS does it this way as well.
If I didn't make myself very clear, the BView actually owns the bitmap (I 
think), but the app_server does all the rendering. I know I didn't word 
things very well - I had a long day yesterday, so my English degraded into my 
native tongue, Gibberish. ;)

>While I agree that knowing the full app_server protocol would be 
>helpful, I think the time necessary to decode it will be much better 
>spent designing and implementing it ourselves.  I think the basic 
>question is this:  what elements does the protocol consist of?  These 
>things certainly:
>
>* Registering and unregistering the application with the 
>app_server/roster.
>* Registering and unregistering each window with the app_server
>* Communicating drawing commands to the app_server
>* Sending updated window & view information to the server-side windows
>* Retrieving window & view information from the server-side windows 
>(only a few things are cached on the client side)
>* Retrieving system/roster information from the app_server
>
>I don't think there's much else, is there?  If there is, surely we'll 
>figure it out as our technical specs get fleshed out, no?
It's definitely a start, if not complete. While I'm thinking of it, which do 
you think would be more efficient, using read/write port or BMessages?

--DW

Other related posts: