Skip to main content

[jsr360-observers] [jsr360-experts] Re: Re: Re: JSR 360 EG GCF remarks

  • From: Lampart Thomas < >
  • To: " " < >
  • Subject: [jsr360-observers] [jsr360-experts] Re: Re: Re: JSR 360 EG GCF remarks
  • Date: Fri, 15 Mar 2013 13:42:33 +0100
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US
  • List-id: <jsr360-experts.jsr360.java.net>

Hi Michael,

 

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

  Thomas

 

 

From: Michael Lagally [mailto: ]
Sent: Donnerstag, 14. März 2013 14:26
To:
Subject: [jsr360-experts] Re: [jsr360-observers] Re: Re: JSR 360 EG GCF remarks

 

Hi Thomas,

 

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.

 

Best regards,

 

Michael

 

On 14.03.2013, at 09:25, Lampart Thomas wrote:



Hi Michael,

 

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.

 

Kind regards

  Thomas

 

 

From: Michael Lagally [ ">mailto: ] 
Sent: Mittwoch, 13. März 2013 20:40
To:  ">
Subject: [jsr360-experts] Re: [jsr360-observers] Re: JSR 360 EG GCF remarks

 

Hi Thomas,

 

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.

 

Best regards,

 

Michael 

 

 

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.

 

Kind regards

   Thomas

 

 

 

From: Michael Lagally [ ">mailto: ] 
Sent: Donnerstag, 7. März 2013 07:47
To:  ">
Subject: [jsr360-experts] Re: [jsr360-observers] Re: JSR 360 EG GCF remarks

 

Dear Thomas,

 

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.

 

Best regards,

 

Michael

 

 

 

On 05.03.2013, at 13:05, Lampart Thomas wrote:





Dear Michael,

 

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.

 

Kind regards

   Thomas

 

 

 

From: Michael Lagally [ ">mailto: ] 
Sent: Dienstag, 5. März 2013 11:44
To:  ">
Subject: [jsr360-experts] Re: [jsr360-observers] Re: JSR 360 EG GCF remarks

 

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,

Unfortunately I will not be able to attend the call on March 6th. Therefore I would like to present a couple of remarks here for your consideration:

1.) AccessPoint: I really like the concept but I think it is not going far enough. The AccessPoint concept seems to be limited to discovering access points and using them for IP traffic. The aspect of configuring them or controlling them seems to be outside the scope? That is probably supposed to be done by some software outside of Java?

 

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.

 

Now on a typical headless Java device there probably is not much software outside Java and especially no one who could configure or control an access point. All needs to be done by a midlet. 
So it would be nice to actually allow a midlet to configure and control an access point. For a access point which requires some sort of "dial-up", like 2G/3G modems that would for example involve methods like "dial" and "hangup" and also additional parameters/properties like "username" and "password". 

2.) CommConnection: This interface has always been lacking support for the additional control lines (RI, DCD, DSR, DTR), which are often present in physical interfaces of that sort (RS232). Maybe that's now the chance to add such support, since in headless devices these control lines are often required by some hardware which is connected. So a midlet supposed to control this hardware and using the CommConnection interface needs to be able to handle the control lines.

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. 

Kind regards
 Thomas




Best regards,

Michael

 

On 05.03.2013, at 11:03, Werner Keil wrote:






Dear Thomas/all,

 

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.

 

Kind Regards,

Werner

Dear JSR360 specleads and experts,

Unfortunately I will not be able to attend the call on March 6th. Therefore I would like to present a couple of remarks here for your consideration:

1.) AccessPoint: I really like the concept but I think it is not going far enough. The AccessPoint concept seems to be limited to discovering access points and using them for IP traffic. The aspect of configuring them or controlling them seems to be outside the scope? That is probably supposed to be done by some software outside of Java?
Now on a typical headless Java device there probably is not much software outside Java and especially no one who could configure or control an access point. All needs to be done by a midlet.
So it would be nice to actually allow a midlet to configure and control an access point. For a access point which requires some sort of "dial-up", like 2G/3G modems that would for example involve methods like "dial" and "hangup" and also additional parameters/properties like "username" and "password".

2.) CommConnection: This interface has always been lacking support for the additional control lines (RI, DCD, DSR, DTR), which are often present in physical interfaces of that sort (RS232). Maybe that's now the chance to add such support, since in headless devices these control lines are often required by some hardware which is connected. So a midlet supposed to control this hardware and using the CommConnection interface needs to be able to handle the control lines.

Looking forward to getting some feedback on this.

Kind regards
  Thomas




 

 

 



 

Michael Lagally | Principal Member of Technical Staff

 

 

Oracle Java Development Group | Mobile & Embedded


 

">

Phone: +49 89 1430 2620

Mobile: +49 172 818 71 91

 

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande 
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

 

 

 

Michael Lagally | Principal Member of the Technical Staff

 

 

 

 

Oracle Java Development Group | Mobile & Embedded

 

 

 

Phone: +49 89 1430 2620

Mobile: +49 172 818 71 91

 

 

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande 
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

 

 



 

Michael Lagally | Principal Member of Technical Staff

 

 

Oracle Java Development Group | Mobile & Embedded


 

">

Phone: +49 89 1430 2620

Mobile: +49 172 818 71 91

 

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande 
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven



 



 

 

Attachment: CommConnectionControlLines.html
Description: CommConnectionControlLines.html

Attachment: CommConnectionControlLinesListener.html
Description: CommConnectionControlLinesListener.html



[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

(continued)

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Lampart Thomas 03/12/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Werner Keil 03/12/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Werner Keil 03/13/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/13/2013

Message not available

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/13/2013

Message not available

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/13/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/13/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Lampart Thomas 03/14/2013

[jsr360-observers] [jsr360-experts] Re: Re: JSR 360 EG GCF remarks

Werner Keil 03/14/2013

[jsr360-observers] [jsr360-experts] Re: Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/14/2013

[jsr360-observers] [jsr360-experts] Re: Re: Re: JSR 360 EG GCF remarks

Lampart Thomas 03/15/2013

[jsr360-observers] [jsr360-experts] Re: Re: Re: Re: JSR 360 EG GCF remarks

Michael Lagally 03/18/2013
 
 
Close
loading
Please Confirm
Close