[Dev] suggestion: proxy daemon/client architecture proposal

[Bruce Dykes]

--- Jack Bell <jackb at sff.net> wrote:

> Also, is some important purpose served by doing this
> as a 'daemon' 
> or 'service'? I would rather see a set of libraries
> which could be the basis 
> of a daemon, or could be imported directly into the
> calling code. Once again, 
> this improves reusability. Please do not make the
> mistake of being certain you 
> know how everyone will want to use the core Chandler
> code! Instead create 
> modular components that can be snapped together in
> interesting ways and let 
> people put their own layers of abstraction on top of
> them.

I think we're speaking at two different levels of
detail here.

All I expect from Chandler the application is a clean
divorce between the presentation layer and the process
layer. I'm using daemon in the traditional sense, a
program that runs continuously in the background to
perform tasks and handle events. If you look at some
the planned features, some are obvious, such as
peering calendar data, but some aren't at first blush,
such as network time syncing, and task scheduling. And
of course, new mail notification.

I think you're speaking of lower detail than that. I
for one don't care if the source is a gnarl of C++
worms, I'm not going to be reading it. I will,
however, be looking at the APIs for the daemon, and
probably doing some scripting with the inevitable
pyChandler module.

> I have a lot of ideas about this, but I have been
> waiting until the OSAF guys 
> started posting on this list. Perhaps I should just
> jump in?

Jump in, the water's fine...

bkd

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/