[interfacekit] Helping with the Interface Kit

Hello all!

Some of you have heard back from me already, some have not; my apologies 
to *everybody* for having sort of gone dark.  My day job looked ready to 
go ballistic and my ISP quite suddenly went out of business, so my 
schedule and connectivity have been a little touch and go lately.  
Fortunately, the day job situation has improved *dramatically* and my 
DSL will finally come back on the 12th, so hopefully I'll be more 
available and responsive.

What we're taking on is quite large, so all the help possible is 
appreciated.  I'll be signing you all up for the interface kit mailing 
list (interfacekit@xxxxxxxxxxxxx) as this is where we do nearly all our 
communication; archives are available at 
http://www.freelists.org/archives/interfacekit/.  DarkWyrm has done some 
excellent background work on app_server architecture; check out his 
posts titled "Structure of the App Server", "App Server startup 
procedures and Question," and "AtheOS Window Management: A First Look."  
He's also been doing a lot of prototyping work with BDirectWindow to 
suss out what the lowest layer of app_server will look like.

Some of you have already heard this part, so feel free to skip it.  At 
this point, the team is all about design and architecture, with 
prototyping as necessary.  We're not looking to craft production quality 
code right now.  We have to figure out how a lot of stuff is going to 
work (heck, I'm still trying to figure out all the things we need to 
figure out ... ;) and do a thorough job of documenting our design and 
the decisions behind it.  As you can imagine, none of this refers to the 
actual API; Be, Inc. quite graciously took care of that for us. =)  The 
real task is determining:

- what the app_server does (some of DarkWyrm's posts mentioned above go 
into this)
- how the app_server does it
- how the interface kit (and others) communicate with the app_server and 
vice versa
- how the guts of the interface kit work

This is a pretty high-level list; there are certainly a boat-load of 
design tasks within each of those items.  To head off any controversy at 
the pass, we are *not* considering using Qt or GTK+ for the 
underpinnings of app_server; we are, however, planning on otherwise 
using whatever existing software we can to make our job easier (FreeType 
for text rendering comes to mind).  API-level compatibility is an 
absolute must, but our real goal is full binary compatibility for apps 
which rely on the public API interfaces.

Don't be discouraged if you aren't an uber-coder; all of the interface 
kit controls and things like preferences applets will need to be 
(re)written, too.  There's *way* more than enough for everybody to do.

At any rate, welcome aboard.  I look forward to hearing your ideas and 
working with you to make this thing happen.

e

PS:  I realize a mass-mailing like this is pretty impersonal.  My logic 
is that it's more important to the project for me to get people actively 
involved than to let even more time go by while I craft thoughtful 
replies; I hope nobody is too put off by it!

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

Other related posts: