[Portland] The Plan

[Lubos Lunak]

 Hello,

 Ok, so much for silly mail subjects :). I guess now we need a plan to 
proceed, so I'll give it a try. I'll use separate mails for some of the 
topics that potentionally can lead to larger discussion, the simple rest 
here:

- There's repository, so that's where the development will take place, instead 
of putting tarballs somewhere. I'll put what I have there after I get the 
most recent code I have to a usable state again :), then we can 
extend/rewrite/whatever based on discussions here.

- License: as it's expected all kinds of apps will use it, including linking 
statically and whatever, everybody should use a very free license. I'll put 
all my code under the BSD one. Including daemons, those should be generally 
rather simple code too that we want everybody to use, there shouldn't be much 
to protect, and it should be simple to start another daemon.

- What to standardize: I think there should be all of these 3 standardized: 
The abstract API, the wire format, the C (or whatever) API. In this order, 
more or less, the abstract API being primary. That should make it simple to 
switch to another wire format later if needed or change the C API without 
affecting other parts. Standardizing the wire format should actually 
standardize something that's real and allow other bindings than just the 
basic C ones. And as presumably most apps would use the the C bindings those 
should be standardized too (the abstract API calls preferably described as 
"string is const char* for in arguments and char** for out arguments, use 
free() for the out argument afterwards").

- Ensuring backwards API compatibility: Every call will have its ID, most 
probably an int like it's now. Can be created as a part of the autogeneration 
of code from the abstract API description or can be specified in the abstract 
API description. There will be one call that'll return a list of all calls 
the daemon implements, this will make it possible to detect some 
functionality is missing and fall back (see later on fallbacks). Also, 
adding/extending/altering calls will be simply implemented by adding new 
calls with new IDs, in C API this will probably result in some of foo_2, 
foo_3 or whatever. See later (another mail) for backwards wire compatibility.

- How to design new APIs: There should be probably some "process" for this, so 
that we don't end up with some random mess that'll have to be patched 
repeatedly. I'm actually a bit lost here as I have no idea what ISVs would 
want/need. Ideas?

- Backwards compatibility in daemons: Daemons should preferably support 
everything including the oldest and crappiest. This hopefully shouldn't be 
that bad as it should generally mean just handling older calls with less 
arguments or whatever. Somewhen later it could be even possible to drop very 
old calls, with the help of the call providing a list of all functionality 
supported in the daemon and the fact that very old clients in such case would 
simply fall back then. If deemed worth it, that is. In the case of possibly 
changing the wire format (that includes switching to DBUS or whatever) 
completely somewhen, the daemon then should simply accept calls from both 
wire formats, process them the same way and send back the way they came.

- Wire backwards compatibility: Uhm ... I guess we'll need to get this one 
right quite soon. Some minimal possibilities for changes came from this 
initial testing period, from possibly changing wire format completely, and 
finally from the fact that even the wire format should allow some changes. 
The idea is roughly that one message will be something like { int id; int seq; 
int length; ... the rest depending on length ... }, so adding new calls with 
new id's could hopefully allow even larger changes.

 Ok, separate mails for the remaining issues so that it's easier to comment on 
those.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/