On Sat, 11 Jan 2003 [EMAIL PROTECTED] wrote:
> On Sat, 11 Jan 2003, Roger Lindsjo wrote:
>
> >I'm not to fond of setting the variable storage type (not variable type)
> >in front of the methods. Hungarian notation at least tells what type of
> >value the variable holds. But I see your point of following the PSecs
> >notation.
>
> My feeling is, as long as the names (besides the storage type prefix) are
> the same as what's in the USB spec, I don't care too much what the prefix
> is. I originally started changing the names because many of them
> didn't match the USB spec at all, e.g. bConfigurationValue() used to be
> getConfigNum()...
>
> Anyone else prefer get<field> instead of b<field>, w<field>, etc...?
After looking some more at the specs I realized that some methods actually
use Hungarian Notation (i -> Index, bcd -> BCS, id -> ID) but sometimes b
is used that could be number or protocol, and w is word...
I think your original idea is better, keep it the same as the specs (even
though I think it is ugly) since this will probably make it easier for
developers familiar with the USB specs to use this implementation.
> >This issue is still foggy to me. Does anyone here have the 2 books
> >referenced at page 205 in the usb spec? ("The Unicode Standard, Worldwide
> >Character Encoding, Version 1.0 Volume 1 & 2" The Unicode Consortium,
> >Addison-Wesley Publishing Company.) Section 9.6.5 in the USB specs only
> >says UNICODE encodings, but to me this gives a whole range of possible
> >encodings. And there is no way (that I can see) to find out which encoding
> >is used. I'm guessing UTF-8 is used, but I do not know.
>
> I believe it's UTF-16 Little-Endian. In the StringDescriptor RI
> implementation, I try to use several encoding that are usually present,
> and default to ASCII (only if the string is pure 8-bit, i.e. no high bytes
> are non-zero). From what I could find in Java documentation, the best
> (only?) encodings to use are: "UnicodeLittleUnmarked", "UnicodeLittle",
> and "UTF-16LE". For more platforms and JVMs, that should work, but it's
> possible none of those are present, maybe for J9 or something. J9 is
> crazy.
Yeah, seems reasonable, but you'd think that with such a massive spec as
this is there wouldn't be ambiguities like this.
the waitUntilComplete is only in DefaultUsbIrp, not in UsbIrp. What is
your reasoning here? Do you anticipate implementations where UsbIrps could
not perform this "operation"?
//Roger
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
javax-usb-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
