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 ;)
