APIs (Re: [Portland] The Plan)

Lubos Lunak l.lunak at suse.cz
Wed Mar 1 17:51:02 EET 2006


On Wednesday 01 March 2006 01:41, Bryce Harrington wrote:
> On Wed, Mar 01, 2006 at 01:15:21AM +0100, Lubos Lunak wrote:
> > - 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?
>
> Perhaps as a start, just provide a guideline document covering the basic
> cases, perhaps pointing to a good reference example?

 So you volunteer :) ?

 Also, assuming I'm getting right what you said (it seems to me you're talking 
about documenting the APIs for app developers), that's not what I meant. I'm 
talking about creating the APIs - what to add and how exactly it should look 
like. Even out of the 10 calls that I have at least 6 still need changes and 
are not final (they need a mainwindow they relate to or startup notification 
info, otherwise they'll be wrong with focus stealing prevention).

 Ok, unless somebody has a better idea, let's do this:

- I have already all calls from the Short Term Tasks from 
http://freedesktop.org/wiki/PortlandIntegrationTasks that make sense to be 
calls (installing apps/launcher/mimetype-handler is done by putting .desktop 
files somewhere and as such it doesn't need API). Plus I have the few more I 
consider useful.

 If somebody, preferably some ISV so that we don't add might-be-perhaps-useful 
stuff, wants something more, be it from the medium/long term tasks or 
something else, say what you need. And try to be precise. "I want to query 
the addressbook" is a good start, but it's barely a start.

- For every call, we need a specification for API.txt that describes the API 
call precisely including its functionality. I consider what's in API.txt to 
be sufficient for the calls that are already there. We just need to check if 
there aren't some problems waiting for or if there isn't something more 
wanted from the call. As already mentioned many of the calls currently have 
the problem of missing relation to the application's window. For the 
LocalFile/UploadFile there it perhaps might be useful to have progress 
callbacks. This needs to be sorted out.

- For testing we can mark calls experimental, unsupported, etc. They'll be 
implemented but they may still change later.

- After a call is deemed to be okay, it's marked stable, implemented and 
whatever.


-- 
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/



More information about the Portland mailing list