Hi, I'm quite busy this year (normally will have a bit more free time after summer).
Never used CTS/RTS and never on Windows (tested serial transport on windows only recently). Perhaps it's a rxtx issue ? For the other problem, could you please fill a JIRA issue with details and/or test case ? Thanks Julien Le Wed, 17 Jun 2009 17:36:26 -0400, boB Gage <[email protected]> a écrit : > Opps!! Forgive the previous, hit send before I even started > typing.... :-( > > Like I said, it's not really my call. Any development I do wrt this > project is owned by my boss, not me -- I've got no problems > contributing to the project, but I don't own what I write. > > Yea, personally, had I been the one making the decisions, I would've > gone with Mina 1.x (whatever the last stable release was) and planned > on upgrading to 2.0 after it was finalized. But it's way too late > to go back now. :-) > > If ya really do want the whole picture.... :-) > > I'm also seeing a flow control problem. Once attempting a protocol > requiring hardware flow control (CTS/RTS) on a port, that port cannot > be used again. Once the RTS/CTS-desiring protocol uses the port > (and fails to get the response it wants) all further connections > generate PortInUseException's on open attempt until the program is > stopped and restarted. This particular issue has only been seen on > Windows systems -- the same code running on a Linux machine works > just fine. > > boB > > > > Emmanuel Lecharny wrote: > > boB Gage wrote: > >> Emmanuel, you're right.... I should be annoyed at the previous > >> designer that tied our non-volunteer project with strictly defined > >> deadlines to a volunteer-developed library tool set; not at the > >> volunteers who never actually committed to support anything. > > well, it's always the same story : even if you have selected a > > close source API, even if you have paid a huge amount of money for > > it, it could still contain bugs, and you could still be stuck. > > > > We are really trying to do our best to deliver the best quality > > software, and it's not easy. Julien, for instance, is using MINA > > with the serial layer (he coded it) for its own usage. Obviously, > > he is ready to pay the price for it (ie, time on his own hours), > > not only because he needs it, but also because he sees the > > immediate benefits he can get from such a piece of software : a > > community around it which can help if he gets stuck in some part of > > the code. > > > > If I can send a message to all the users : it's really easy, and > > rewarding, to become a committer. It's a matter of participating by > > providing patches. > > > > Also note that we never spread the wrong signal that MINA 2.0 was > > ready. It's still a milestone, and designed as unstable. Yes, I > > know, it takes forever to get a release out... > >> > >> Problem is I've got umpteen different things that have to be fixed > >> and added at our level of the application and this is neither the > >> first, nor even the only active issue in our code likely caused by > >> Mina. I've hesitated to mention the other active issue, so as > >> to not muddy the waters -- one problem at a time. :-) > > Well, sometime, it's better to get the whole picture :) > >> > >> Unfortunately, I don't think the designer who decided on Mina > >> realized that we were taking it places it apparently has never > >> been before... What we needed was a cross-platform answer to a > >> serial application; the tool he chose was Mina, whose serial-side > >> is apparently new and I'm finding not overly bug-free. Our > >> application is being used in a health care setting so should be as > >> bullet-proof as possible. > > This is what we are targetting too. A slipery path, too... > >> > >> I'll have to ask my bosses about patches. It's really two > >> questions. Do they want to pay me to fix Mina library? If so, > >> are they willing to then give away those fixes to the community at > >> large? I'm on someone else's payroll, so I don't make those > >> decisions. > > You have two options here : > > - you can fork MINA, if for any legal reasons you can't or don't > > want to share the patches, > > - or you can grant the patches to The ASF > > > > I understand that's not as simple as willing to contribute to the > > project. > > > >> > >> boB > >> > >> PS... Okay, so say I do have to dig and fix this myself. How > >> would I confirm my Mina svn repository matches the M4 code I'm > >> using before I muck around with it? Or do I have to update to > >> the latest Mina code first? (M2 to M4 got ugly; M4 to M5 looked > >> horrible and was quickly reversed, been waiting for the real > >> release ever since) > > Let be clear : M4 sucks, M5 is even worst. M6 is way better. Trunk > > will be (hopefully) even better. In any case, you can pick the > > milestone you prefer, in the tags/ directory : it's frozen. When > > you would like to move to a more recent version (say, M7 when > > ready), it's just a matter to merge your modification into the > > trunk. as we aren't modifying the code a lot atm (we are just in > > bug fix mode), that should not be a problem. > > > > Hope it helps (a bit ;) > > >
signature.asc
Description: PGP signature
