We have such a “CommConnection Extension” as proprietary API in our products since years.
Please find attached the two relevant .html pages from our Java docs for your consideration.
Sorry, that’s only an excerpt and the html links will not work, but I think this should give a good impression what kind of API we envision.
Have a nice weekend
how do you think the extension of the API for control lines should look like ?
Would these be just a few methods to select a HW-handshake behavior,
or do you think of something else ?
More details / or a small proposal of the Comm API extensions could help to
determine how / where to do this.
On 14.03.2013, at 09:25, Lampart Thomas wrote:
I am not sure what kind of “more close to the hardware” API you envision and where such an interface would be defined. Probably deviceaccess ? Actually CommConnection is the perfect API to handle a UART like interface. Everything is there. Even baudrate and framing configuration (which is indeed something pretty close to hardware ;)
Only the means to handle the control lines are missing.
to me it seems that this is a use case that may require a different abstraction than the stream based comm connection.
A peripheral API could offer a better, i.e. "more close to the hardware" level of interface.
On 12.03.2013, at 10:13, Lampart Thomas wrote:
Hi Michael and experts,
Sure. A typical use case is:
There are legacy devices (e.g. copier) which used to communicate via fixed line modem (CSD). Fixed line modem typically have a UART interface and use the UART control lines, line RING, DSR, DTR to signal status.
When these legacy devices are upgraded to wireless communication, a Java enabled wireless modem is connected via UART instead of the fixed line modem. Now a Java application is written to imitate the behavior of the fixed line modem. This way there is no need to change the software in the legacy device. However the Java application now needs to be able to control the UART control lines because this needs to be part of imitating the fixed line modem.
we initially discussed your comments in today's JSR 360 call but will revisit them in the next call (in 2 weeks).
It would be very useful to have application use cases for control of RS 232 handshake line by the application.
On 05.03.2013, at 13:05, Lampart Thomas wrote:
To 1.) I am not really sure if it makes sense to separate the configuration and control functionality from the “AccessPoint”. Does a draft for such a higher layer API already exist ? Or maybe just an idea how these two would then fit together ?
To 2.) yes, the issue is about notifications for incoming and set methods for outgoing control lines on the application level.
Dear Thomas, Werner,
thanks a lot for your comments, they are very useful.
Please see in-line for comments and further questions:
On 05.03.2013, at 09:57, Lampart Thomas wrote:
Dear JSR360 specleads and experts,
The API currently currently treats access point just as a means to select the access point without attempting to define a common API for configuring these for various technologies.
Configuration and control should be handled at a higher profile level for the individual connection technology,
such as a cellular network API that is considered as part of the ME-EP for cellular networks.
What would you need ? Is it just a way to select hardware vs software flow control or do you see a need to receive notifications about changed lines at application level ?
Looking forward to getting some feedback on this.
On 05.03.2013, at 11:03, Werner Keil wrote:
Sorry you can't make it tomorrow.
About 2.) I thought physical interfaces were more subject to a yet to be defined Device API, but if there's anything in CLDC like CommConnection that would be a good foundation to that, I am very interested to hear more. My late father won't be able to connect his measuring devices via RS232 to Java apps any more, but your mention of that shows, he may not have been the only person to still having used such interfaces in times of USB or "Lightning"<329.gif> And although they probably abandoned DDE the smart greenhouse automation vendor I wrote the mentioned Java connectivity for probably also still uses this interface for their devices.
Dear JSR360 specleads and experts,
[jsr360-experts] Re: [jsr360-observers] Re: JSR 360 EG GCF remarks
[jsr360-experts] Re: [jsr360-observers] Re: Re: JSR 360 EG GCF remarks