Re: gpilotd questions...

[jrb redhat com]

> I concur reg. using a random number for SyncId (currently I've been using
> the last two bytes of the hosts IP, since this also allows some id of the
> machine, don't know if that seems useful to anybody then me).

I went ahead and split up gpilotd some.  I only did it in the main
branch, but it was fairly clean, so I hope you won't have problems
with the corba branch.  

> The branch tag is gnome-pilot-corba, and it's actually almost usefull now
> (only file install currently implemented) with working callbacks etc. I've
> begun implementing the set/get user info calls, may have them working this
> weekend, otherwise hopefully during next week.
> 
> I'm also encapsulating the corba calls into a lib, like libpanel_applet.

Sounds useful.  I'll check it out sometime later this week and see if
I can get them hooked up with the capplet stuff.

> Currently, eg. the memoconduit's deprecated run_config call launches
> memo-conduit-properties with the pilot id as first argument. What we all
> probably want, is a capplet for each conduit. The user should then be
> presented with all the installed conduits, and each conduit should have a
> radiobutton for one of the 4 sync methods (and a off option of course).
> 
> And in addition to this, any conduit specific config options ofcourse.
> Currently, only the memoconduit has any settings.

Hmm...
I actually like the old way a bit better, but that's ok.  I'm not sure
that a seperate capplet per conduit would scale well to multiple
pilots.  I was thinking of having a list of conduits per pilot.
You could simply select the conduit you want to configure and pop up a
dialog box to do it.  Seems a lot cleaner to me then a per-conduit
capplet.

Anyway, I'm looking into writing a conduit of my own (the address book
one.)  I assume no one wanted to work on that, but I thought I'd ask
here first.

-Jonathan