[Rxtx] Which Java folder in source?

[Steffen DETTMER]

* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] 
> My question would be: Why would you do that? The rewrite does 
> most of the work for you - all you have to do is implement 
> two C++ virtual classes and two C++ functions.

You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/?
I just took a short look, maybe it could be discussed further,
but I don't think I like it much.
BTW, the main interface defined there is called gnu.io.Dispatcher?
I thought the package names should be used in a way to avoid clashes,
e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name
space authority :)).

> In Windows that took me a few hours.

where is the implementation?
I found
commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp
with things like

const bool SerialPortImpl::isDataAvailable() const
{
    // Needs implementation
    return true;
}

and

    timeouts.ReadIntervalTimeout = MAXDWORD;*
    timeouts.ReadTotalTimeoutMultiplier = 0;
    timeouts.ReadTotalTimeoutConstant = 0;
    timeouts.WriteTotalTimeoutMultiplier = 0;
    timeouts.WriteTotalTimeoutConstant = 0;
    if (!SetCommTimeouts(hComm, &timeouts))
        throw IOException();

which seems to be oversimplified or some prototype only?

I think (and I wrote about this already in the past years) that correct
timeout handling is one of the challenges, so I think this should be
prototyped first - for each system flavor - before cementation of the
(JNI-) interfaces. Personally, I would vote to form it in a way allowing
to be implemented on embedded devices, for example.

Another big challenge is to prove a rewrite fully working (and probably
compatible to the old implementation) on "all" the supported OSes. Not a
big problem for linux and windows, just use some thousand lines test
code, test drivers and serial loopbacks etc, but for the exotic
platforms, probably a high number of, this probably won't be too easy...
(there are more challenges, such as being comfortable and threadsafe
[are read and write permitted at the same time?], detailed and helpful
exceptions on user API level [not necessarily on JNI/JNA layer], how to
have a configurable threadsafe logging/tracing [maybe also from native
code to assist porting / testing on exotic OSes, such as OSes where the
developers have no direct access too, which can be quite hard to usually
leads to good log messages], just to name a few.).

So even it might seem easy for one platform and I agree with Micheal
that

> >   * yay! let's start a rewrite

is unlikely to succeede soon...

However, when considering this, before IMHO a powerful Java API has to
be defined, because according to my experiences for implementing
non-trivial protocols InputStream/OutputStream might not be
comfortable/powerfull enough (eventually I consider both wrong) and have
some InputStream derivation available as wrapper (so applications can
use InputStream and whatever high-level-API they want).
The JNI interface shall make such a powerful implementation possible,
thus the interface of it is driving the JNI interface design and thus I
think it had to be done first.

All this surely requires much work: agreements on the APIs, safeness for
the users, design, documentation, all the implementations and the
testing. As long as such bug amount of work cannot be spent, for example
if some employee would get half a year time paid for it or so :-),
probably it is unlikely to progress on this.

Otherwise, I'm afraid, patches, improvements, new design ideas and even
rewrites wouldn't become complete and thus won't form a new rxtx version
(3.0); thus either collect dust in some forgotten CVS branch or could
generate a split...

> I can't imagine other ports taking 
> much longer than that - especially since POSIX-based code can 
> be shared between ports.

Things are more complex than they seem to be...

I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select
on serial ports isn't supported; maybe it is non-trivial to "map" (like
mapping select() to WaitForMultipleObjects() which might have different
semantics etc.) or maybe some different approach has to be used. A
system may have POSIX like termios interfaces but not support timeouts
or have any other interoperability bug... 
You never run out of things that can go wrong. And if something can go
wrong, it will... :-)

Or, as Michael wrote:

> > I seriously don't believe anyone will come up with anything better
anytime soon.

oki,

Steffen

 
About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. 
http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail