Skip to main content

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

  • From: Michael Lagally < >
  • To: Werner Keil < >
  • Cc:
  • Subject: [jsr360-experts] Re: [jsr360-observers] Re: JSR 360 EG GCF remarks
  • Date: Wed, 13 Mar 2013 20:50:52 +0100

Hi Werner,

we announce the calls one week in ahead to make sure that EG members can plan accordingly.

You can always find the date of the next call in the call notes. (see below)

Thanks,

Michael


Begin forwarded message:

Subject: [jsr360-experts] JSR 360 EG call notes - Wed 6.3.
Date: 6. März 2013 16:33:29 MEZ

Dear JSR 360 experts,

here are my realtime notes of today's EG call. Please point out any significant omissions or errors.

Call Participants:
Roger Riggs, Oracle
Hernan Perrone, TOTVS
David Campelo, TOTVS
Werner Keil
Yagami Huang, Aplix
Michael Lagally, Oracle

New EG member:
David Campelo from TOTVS recently joined the JSR 360 expert group. The SpecLeads and Experts welcome him to JSR 360.

EG feedback / questions:
• Thomas' (Cinterion) comments were initially discussed and will be revisited in the next call, when Thomas is present:
- Access point APIs - Configuration APIs for access points
- From a CLDC perspective, configuration of access points has been considered either as part of the native platform or
to be addressed in a higher level profile. 
- It was perceived to go beyond the scope of CLDC to define a common abstraction / generic API, that would enable
the configuration of bluetooth, WIFI, mobile networks 

- Comm Connection - API support for RS 232 handshake lines
- Use cases would be very useful to better understand how an application needs to control the serial lines  

• Werner's comments:
- @since tags
- An overview HTML page will identify all classes, that are new in CLDC 8. There can be multiple since tags in a Java file
and  the CLDC 8 tags will be added to the spec 

SpecLead draft - top level walkthrough on GCF
•  The SpecLeads walked through the Goals and Requirements for GCF, which provides a consolidated specification
by combining parts that have been previously handled in different specifications.
  •  GCF enhancements include a flexible mechanism to provide protocol specific additional parameters (ConnectionOption),
       IPv6 support, UDPMulticastDatagrams and a unified security model

EG members are encouraged to continue reviewing the Specification draft and to raise comments and questions to the SpecLeads,
preferably over mail to allow for preparation to discuss them in the next call.

Early Draft Review (EDR):
As communicated in the JSR timeline at the kick-off call, an early draft release of the JSR is planned for March.
The objective of the EDR is to gain early feedback on the specification draft from a wider audience to leave enough time
for further EG work.
The EG is asked to review the SpecLead Draft within the next two weeks to identify any issues and potential blocking points for an EDR.

Next Call:
The EG call next week is cancelled due to unavailability of both SpecLeads. 
The next EG call will take place on March 20th at 12am GMT/UTC. 
Please observe the DST changes in some regions of the world.
  
Scope will be to answer EG questions on CLDC / GCF and to identify any blocking points for the EDR. 

Best regards,

Michael






On 13.03.2013, at 15:33, Werner Keil wrote:

Thanks, sorry I missed that, be a bit more used to short-notice cancellations or as for yesterday's 351 EG call the Spec Leads sent another mail confirmation out to everybody on the mailing list.

I happened to be in the call last week, but a couple of other EG members weren't.

Werner

On Wed, Mar 13, 2013 at 3:28 PM, Michael Lagally < " target="_blank"> > wrote:
Hi Werner,

in the call last week we agreed to cancel this week's call due to Rogers / my absence 
and to have the next call on Wednesday next week. 

Best,

Michael


On 13.03.2013, at 14:21, Werner Keil wrote:

Michael/all,

Was there no CLDC call today, or was it shorter than usual??

I just dialed in (given, the time was CEST I assumed that would not change despite the US Daylight Saving) and was the only one in the call. Even if it had started 1h earlier, it would normally still have been on after 1h, unless of course, there was too little participation or too little to discuss?

Thanks,
Werner

On Tue, Mar 12, 2013 at 11:23 AM, Werner Keil < " target="_blank"> > wrote:
Thomas/all,

Isn't this more a topic for the still pre-proposal stage Device Access and Control API?

Werner

On Tue, Mar 12, 2013 at 10:13 AM, Lampart Thomas < " target="_blank"> > 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: " target="_blank"> ]
Sent: Donnerstag, 7. März 2013 07:47


To: " target="_blank">
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 [ " target="_blank">mailto: ] 
Sent: Dienstag, 5. März 2013 11:44
To:  " target="_blank">
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

 

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



 



 

 










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

(continued)

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

Michael Lagally 03/05/2013

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

Werner Keil 03/05/2013

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

Lampart Thomas 03/05/2013

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

Michael Lagally 03/07/2013

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

Lampart Thomas 03/12/2013

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

Werner Keil 03/12/2013

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

Werner Keil 03/13/2013

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

Michael Lagally 03/13/2013

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

Werner Keil 03/13/2013

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

Michael Lagally 03/13/2013

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

Michael Lagally 03/13/2013

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

Michael Lagally 03/13/2013

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

Lampart Thomas 03/14/2013

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

Werner Keil 03/14/2013

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

Michael Lagally 03/14/2013

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

Lampart Thomas 03/15/2013

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

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