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