sdenier / gecosi Goto Github PK

Not an issue, just a question:

I have ported the GecoSI library to C#.Net and would like to publish it on Github too. Since the code is mainly copied from your code but I have done some changes, I am not sure how to handle the licencing stuff. I will for sure also publish it with the MIT licence, but I am not sure how to handle the copyright message.

Is it okey if I write:
Copyright (c) 2013-2014 Simon Denier & Yannis Güdel

Hi @sdenier ,

As discussed last October, I have started another app which uses GecoSI (http://orientbase.org).
While integrating GecoSi in my app, I have made several changes in my fork (check out the v2 branch):

• switched to Gradle for the build and dependency management (not a big deal I think)
• switched from RxTx to jSSC (which works like a charm on Ubuntu and Windows - I will leave the OSX checks to you ;-) )
• a few minor updates...

The goal of this ticket is to track the (high level) changes I would like to implement in the future to have an opportunity for discussion (both with you and any other user of GecoSI).

Threads

This was probably not th case with RxTx but the jSSC lib already creates one thread when you add a listener to a SerialPort... so we currently end up with 3 threads for each open port.
I would think that GecoSI should not create a single thread any longer... Just rely on the jSSC thread
and then let the port listener populate a blocking queue that the lib client would then poll (up to him to create threads at wish: these are architectural considerations well above the scope of such a lib IMO).

Reliability

This may come from my switching to jSSC, but during my testing, I noticed that I could end up with a busy-port error although the OS does not see it open (lsof /dev/ttyUSB0 returns nothing). This occurred when unplugging the readout control etc... so it's not a big deal. In Geco it is not a real issue as it is a single user app, but in cases where multiple users are connected on the app, it would undesirable to have to restart the app to clear an internal busy flag.

Logging

GecoSI should not create log files on its own... instead it should integrate in the logging system of the host program. This could be done by logging against an interface library such as slf4j.

Obviously all this will not be possible by maintaining compatibility with the current existing code, hence the v2 (major version bump).

I will carry on feeding here if anything else arises.
Cheers

Currently punch times for Si6 and + are computed using the 24 hour time, the day of the week as well as the week counter (up to 3 weeks). Experience shows this is a wrong choice as this gives inaccurate times when the zero time (for weekday and week) is unknown and the start time is not registered.

The punch time (24 hour format) should be computed separately (and computed with the shift rule for round-the-clock time) from the weekday and week counter, which should be provided as supplementary data (in case the organiser knows how to handle it).

When the master station is set up in 192 punches mode and a SiCard 10+ is read, all blocks 0..7 are sent by the master station following the 0xEF, 0x08 command - instead of the expected 0, 4..7 blocks.

So Si10+ cards also deserve a special task when read in 192 mode to receive 8 blocks and extract the meaningful data blocks.

For a race setup without start control (start time given by software) and starting in the afternoon, punch times will not be shifted 12 hours as they are only required to be past the missing start time.

Punch times should be shifted past the last relevant time, be it the previous "good" punch time, the start time, or at least the zero hour (as it is for the finish time).