[Rxtx] Which Java folder in source?

[Adrian Crum]

Every journey begins with a single step.

-Adrian

On 3/1/2011 3:25 AM, Steffen DETTMER wrote:
> * 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
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx