On Mar 15, 2005, at 23:31, Dan Streetman wrote:
Hi Dan:
The common RI has a os interface package, com/ibm/jusb/os/, which should
make porting and/or writing from scratch relatively easy (hopefully)...
I hope so too :).
Okay -- I'm digging through the JavaDoc, trying to piece everything together in my mind. I've registered for a new SourceForge project to keep the source in (UNIX name "javaxusbosx"), and hopefully will be able to put a skeleton and a small team together to make this happen.
But before that can happen, I need to wrap my head around both the javax.usb API (from a porting perspective), and OS X's USB APIs (an issue for a completely different mailing list :) ).
I hope you won't mind if I ask some (perhaps apparently trivial) questions to get the ball rolling.
First place to start is to create a UsbServices implementation. There is
an AbstractUsbServices in the os package you can extend. The abstract
package does provide the top-level virtual root hub, but you'll need to
populate the rest of the tree. You can do the population either in a
static initializer or the class initializer. But, the topology should be
fully populated before you return the root UsbHub (or let anyone add a
listener).
Sounds good -- but I guess that before I implement a UsbServices package, I'll need to wrap my brain around how to construct the topology. What is the proper way to do this? Should I (for example) create my own classes that implement (for example) the UsbDevice interface, or should I use the UsbDeviceImp class? On that subject, how do the Usb*Imp classes fit in to all of this?
The rules for creating the topology objects are (should be) defined in
each of the classes, i.e. UsbDevice, UsbConfiguration, etc. The common RI
os-interface could make this process easier, but the current setup
requires the platform implementation to create its own topology objects.
This makes sense.
Once the topology is created, the common RI takes care of a lot of the
API. The method calls coming in are all in the os package interfaces,
e.g. UsbDeviceOsImp.asyncSubmit(), UsbPipeOsImp.asyncSubmit(), etc. Only
the asyncSubmit(UsbIrp) is required to be implemented as all the other
methods can boil down to that method; the os-package classes handle that.
You're free to override any method of course if the platform provides a
better way to implement it (e.g. in Linux, Isochronous submission of Lists
is optimized).
Gotcha. This will probably make a bit more sense as I go along (and learn more about OS X's USB APIs, which I'm completely new to -- at least I've used javax.usb as a developer! :) ).
One thing I'm not yet clear on, is how does the common portion of the API know what native classes to connect into? I didn't see any property files ala the Java Comm API for denoting what native implementation classes to use anywhere.
That's a start at least, don't forget hotplugging :)
I'll be sure to do that, as I need it for my own purposes (other than the new T5, Palm devices don't identify themselves on the USB bus until a sync session is started, and not when they're plugged in).
Thanks for your help thus far. I'm hoping if I can get the pure Java portion started and the JNI headers generated, I can get some community participation to help implement everything.
Please expect me over the coming months to use this mailing list to continue to ask questions :).
Brad BARCLAY, Lead Developer & Project Administrator, The jSyncManager Project.
=-=-=-=-=-=-=-=-=-= From the Mac OS X Desktop of Brad BARCLAY E-Mail: [EMAIL PROTECTED] Web: http://www.jsyncmanager.org
smime.p7s
Description: S/MIME cryptographic signature
