[interfacekit] Re: PortThief

>    Well, this stuff I'm currently working on has to do with screen 
updates 
>and such. I've got a small part of the app_server's interface spec 
done, and 

That's nice to hear. =)

>this happens to be the next bit which needs researched and written. If 
we 
>want binary compatibility, we're going to need to reverse engineer the 
>app_server protocol for BView reasons.

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.

>    If I understand things correctly, BViews have the bitmap which is 
blasted 
>to the screen and the app_server (somehow) has access to it. BViews 
talk to 

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?

>the app_server, but the average joe developer sees none of it on the 
surface 
>- the messages are done via various methods, like FillRect, StrokeArc, 
etc.

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.

Maybe I'm way out in left field; if so, please forgive and try to 
enlighten me. ;)

>    I probably could figure out quite a bit if I understood how to 
interpret 
>data passed in port messages. Understanding this seems to me as 
something 
>pivotal for our team - if we can see what the servers are saying to 
each 
>other, it'd be a cinch, relatively speaking, to duplicate it.

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?

Anyway, unless I'm *grossly* missing the point, I don't think decoding 
the app_server protocol is a good use of your time (in case I hadn't 
made that abundantly clear already =P).

e

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: