[Portland] Summarize current plan?

[Jeremy White]

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


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

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.

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?

Cheers,

Jeremy