Re: Further dev work?

["David A. Desrosiers" <desrod gnu-designs com>]

On Thu, 2007-12-27 at 17:01 -0500, Evan wrote:
> I know it's fairly stable, but it's getting out-dated. I've heard
> various ideas being kicked around that I think are necessary but that
> haven't gotten any work:

>    - migrate from the visor module (deprecated) to hal in order to
>    support newer devices while maintaining support for older ones

Not libusb does not support all USB-connected Palm devices, which is why
libusb is not the default for the library subsystem (you have to build
it with libusb support and do some other setup to get it configured on
your system). 

> - prevent installation of non-prc/pdb files, as they cause errors and
>   lock-ups (this should be really easy?)

This too is going to be a problem with NVFS and external storage. I
regularly sync non-Palm files to my SD card using pilot-link's tools, so
forbidding them entirely isn't a good option. 

Providing a logical method to send non-PalmOS files to external storage
(or error out) is a better solution. 

> - automatically wrap pictures in pdb containers to make them readable
>   by splash-photo (somebody has already written a program to do this 
>   and released it under the mozilla licence, just requires some
>   integration)

Last I knew, SplashData did not release their storage format or provide
any sort of API to write to. Do you have different information on the
matter? 

There is a way to do this with par, but it's not purty.. 

./par c -a "stream" foo.jpg.pdb foo.jpg Foto Foto foo.jpg

> - run an auto-detect to determine which device, connection speed, etc.
>   to use rather than making the user enter it manually (should be
>   easier when hal migration is complete)

Horse => Cart problem

How can you auto-detect which device you have, if you don't know the
right way to talk to it in order to connect and query that information
from the device?

Believe me, if this was easy, we'd have solved it years ago. The problem
is that we have no documentation from any of the vendors, and the
devices they continue to ship, seem to have their own little "quirks",
which some work on some endpoints, others want other endpoints, and the
timing and speeds are completely unpredictable (based on Palm-side CPU
speed, host CPU speed, connection type, driver subsystem, usb host
controller, and so on). 

> I can program in java and .net and I'd be willing to learn c++ or
> whatever to implement some of these, but I don't know where to begin.

Jump in, read the code, and get started. It's all in C/C++ anyway, so if
you know Java, you should be able to understand the code enough to close
existing bugs, or help implement features by adding patches to the
existing codebase.


-- 
David A. Desrosiers
desrod gnu-designs com
Skype...: 860-967-3820