This is just a heads-up to keep those interested parties informed
about what's going on with pilot-link.
I've recently resigned my employment with Linuxcare, and am in a
"holding pattern" as I have been asked to reconsider that decision. I
probably will not reconsider. This means I have a bit more free time on my
hands. Here's what I've been doing with it.
1.) jpr from Ximian has taken some time and converted the entire
pilot-link suite over to a "proper" automake/autoconf build
environment. We're working out the kinks now with some of the
other OS' we would run into (SunOS 5.8 is one we've run into
with a few weird oddities). So far, it builds on BSD and Linux
100% clean (great work, jpr!)
2.) All of the client-facing binaries are getting cleaned up, and
they are all being infused with a proper getopt() structure
(there's a reason for this), and all similar options will act
and breathe similar (i.e. -p will *ALWAYS* stand for 'port'.
Right now, read-ical has a -p option for 'pubtext'. Blecch.)
Does anyone even use read-ical anymore? With Syncal, I would
think we don't need it. Vote to deprecate it?
3.) Once automake/autoconf is working 100%, and all client "conduit"
binaries are updated with the right UI and options available to
them (which includes failing gracefully, and not passing odd
errors), then we begin "collapsing" the redundant binaries into
singular entities. The 'install-memos' and 'memos' binaries for
example, would either be collapsed into one called 'memos' with
a -install option, or pull all the 'install-foo' ones into one
binary called 'pilot-install' with an option -memo. Without the
proper getopt() stuff in step 2, this would be a hackish
nightmare. Work is proceeding fast on this, but Solaris and some
other OS' do not export their own getopt_long() function, so
I've had to fall back on the standard getopt.h/unistd.h getopt()
function.
I'll whip up some screenshots of this later and post them.
4.) USB support can only come last, after the top three above are
working (and 1, 2, and 3 are fairly short-term tasks). The
reason for this, is that there exists a very tight coupling of
the protocols in pilot-link currently, and those have to be
separated a bit, a little surgery if you will, so we can choose
which ones we want based on the device or connection we're
making at the time. If we don't have a clean build system
(autoconf) and a good way to pass options to the binaries
(-usb, -serial, etc.), this would also be a nightmare to
implement.
Did that all make sense? So that's where it stands today. We're
working on things, even though we may not be very vocal here in the list,
things are progressing. The delicate part is that we can't just gut the
backend libpisock protocol layering without breaking things, so we have to
be careful about how we do this so we can still maintain
backward-compatibility with the 0.9.5 build in the interim as the library
matures.
Once we get all that working, the rest of the CSV/XML/vCAL/vCard
stuff should be fairly easy to implement, and the good part about cleaning
up the protocol and collapsing the binaries with more readable code, is that
a "conduit SDK" can be written to wrap around the code that becomes 0.9.6
and beyond.
Ok, I have to jump on a flight to the other coast. I'll be camped
there until 12/5, so I'll be on and off, using d-d-d-dial-up. Blecch.
Have a good week and a great Turkey Day everyone.
/d
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
