[Portland] Summarize current plan?

[Bryce Harrington]

On Sun, Mar 12, 2006 at 03:53:45PM -0600, Jeremy White wrote:
> > Here is a short README to try to address the above points.  If this
> > looks ok, could someone add it to CVS?
> 
> Nice; I have some concerns over technical details (see below).
> but I think it's a huge improvement.  Probably good
> to replicate it into the wiki as well.

Ideally, once it's in CVS, the wiki page can just link through viewcvs,
that way there's just one official place for it to be maintained.

Ultimately, there should probably be a proper website for the portland
project, that would elaborate and illustrate the details better.

> > DAPI consists of two components: A daemon, and a library (libdapi.la)
> > that links to the application.  The library handles the IPC
> > (socket) communication with the daemon and implements the API.
> 
> I have to say that this design freaks me out to some
> extent.  (Now I've browsed the archives, but I'm probably
> still missing some historical background, so forgive me
> if this is just ignorance).
> 
> But it seems to me that the daemon approach is required
> in order to solve some hard problems (not sure I know what
> they are; my eyes glazed over as I read the VFS thread,
> but I trust you guys that we need it).  I also see
> that it could be handy from an extensibility standpoint.

Well, keep in mind this is a prototype, and the purpose is to stimulate
discussion.  Essentially, we're in an early brainstorming process, only
that we're doing it in code and email rather than only email.  So
getting people freaked out is probably a good thing. ;-)

There has also been a discussion around the daemon approach
vs. individual commandline utilities, as well as one around dapi's use
of direct socket IPC vs. using dbus.  There are also additional proposed
prototypes, that illustrate some other ideas (both daemon-based iirc).

Anyway, so keep in mind that rather than the traditional
debate->requirements->code->test->release process, this is using the
FOSS approach of doing it in the reverse order.  ;-)  Sort of "Code
first, ask questions later".
 
> But I could write a simple static library to make a menu
> *right now*, and it wouldn't need a deamon or anything
> else; it should work on any XDG compliant window manager.
> 
> Note that this is possible because I think the menu-spec
> is a nice spec - simple, sweet, and functional.

Right, for things where all the desktop environments do things the same
way, obviously the need for an adapter library is not significant.

Of course, one thing to think about is that unlike open source
applications, commercial/binary-only applications can tend to be
difficult to update.  Thus if the user installs a new version of KDE or
GNOME where the code to implement menus has changed, this library/daemon
abstraction layer would allow the commercial app to continue using the
old style, with the daemon providing a mapping into the new system.  (Of
course, the ideal solution would be that KDE and GNOME never become
non-compliant with the menu spec.)

> I guess I'm surprised that dapi can't be like that;
> a very basic library that I can statically link in
> and magically gain the ability to make a menu.
> I could accept that I might have to add some complexity
> (like bundle a daemon) if I wanted to get fancy,
> but why can't I just have an easy way to make my
> menu appear?

Yep, although menus are probably not the best thing to consider here,
since they do have a standardized spec to them.  In fact, I think there
was a point made that dapi probably shouldn't do menu stuff for just
this reason.

I do know that the static library approach was discussed at the DAM
meeting, although I wasn't invited to that one so don't know what the
arguments pro and con were.  Maybe someone that attended could address
it better.

Bryce