[Portland] Current plan summarized

[Kevin Krammer]

On Wednesday 22 March 2006 17:46, Ian Murdock wrote:
> On Wed, 2006-03-22 at 17:03 +0100, Lubos Lunak wrote:
> > On Wednesday 22 March 2006 14:42, Ian Murdock wrote:

[...]

> > > With a script based approach, you don't have to worry
> > > about ABIs at all, and trust me, if there's a way to do this
> > > without having to worry about ABIS, you want to go that route.
> >
> >  Feel free to, nobody's stopping you (how many more times will I have to
> > repeat this?).
>
> Are we writing code for the sake of writing code, or are we trying to
> solve a problem the ISV community has brought to our attention? I'm
> simply trying to provide some insight here, as someone who isn't
> an ISV himself but who spends a fair amount of time talking with
> them, as well as someone who spends a fair amount of time talking
> to the people we have to convince to ship this (i.e. the distros).

API based solutions offer a better integration especially for data output.
Depending on the data format it can be considerably more difficult on the 
application side to parse the text data returned by  a commandline 
application.

Linux GUI applications are often frontends for commandline tools which enables 
a faster solution than refactoring the commandline tool code into a library 
and then using this library, but also gives the users a less integrated 
feeling than comparable solutions on other plaforms.

E.g early SMB (samba) frontends used smbclient, newer ones use the samba 
client library.

Screenscraping can be used to solve most task, but it is neither relyable nor 
fast nor a solution developers feel comfortable with in the long run.

That's basically why I work on DAPI as well as on the scripts, they are IMHO 
to solutions with different tradeoffs: DAPI takes longer but offers better 
integration, scripts are faster but offer less integration.

Also scripts can only do what the desktops allow commandline interfaces to do 
and are limited to the common ground of all desktops.
For example kfile can determine the MIME type of local files only, 
gnomevfs-info can do it for URLs, for KDE a lot can be done using DCOP, etc

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060322/0338d8b1/attachment.pgp