search

anuragraghavan / franca

Automatically exported from code.google.com/p/franca
0 stars 0 forks source link

Add registration as built-in concept for Franca IDL #34

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Franca IDL has the notion of selective broadcasts. "selective" means that the 
server will not sent a broadcast to all connected clients, but to a selected 
subset of clients only. However, the identification of the clients by the 
server and the application logic selecting which clients should receive a 
broadcast is not part of the IDL. 

This RFC is about how the clients can register themselves at the server and how 
the server can identify its clients. There are various solutions for this 
problem, ranging from "IDL stays as is and everything is done in the 
middleware" up to "extend IDL to provide mechanisms for client identification 
and registration". See the attached file for some details on these options.

Original issue reported on code.google.com by klaus.birken@gmail.com on 10 May 2013 at 2:19

Attachments:

GoogleCodeExporter commented 9 years ago 
The solution for this issue will have a direct impact on the Common API C++ 
project (http://projects.genivi.org/commonapi). The corresponding changes to 
Common API C++ will have to be available at early September 2013 in order to 
meet the deadline for the GENIVI Gemini release (scheduled October 2013).

Original comment by klaus.birken@gmail.com on 12 Jun 2013 at 2:40

GoogleCodeExporter commented 9 years ago 
After discussing with some more stakeholders it seems like proposal 2 (see 
attachment "selectiveBroadcastConcept.fidl") is the most promising one, with 
some extensions from proposal 3.

Proposal 1 requires some central service. This has drawbacks in case of 
distributed systems - what does "central" mean in that case?

Proposal 3 is quite explicit in the IDL, although a big part of the 
functionality can be defined by convention for the underlying middleware (e.g., 
Common API C++ on D-Bus).

Current proposal (derived from proposal 2):
a) Whenever a client subscribes for a selective broadcast the middleware on the 
service side will keep a list of the middleware ids of the subscribed clients.
b) There will be an API which the service can use to access that subscription 
list. The list should be ordered according to the order of subscription.
c) The service can use an extra mechanism to map the middleware ids to generic 
names. The mapping could be provided as config file or deployment model.
d) If needed, the interface may specify a method which allows the client to 
provide additional information which might be used by the server to determine 
the actual broadcast receivers. This feature is derived from proposal 3 (this 
is kind of a register-method, but without a mandatory ClientId parameter). 
However, there is no special IDL support, as this feature is located on the 
application level.
f) Franca IDL is not modified for this solution. 

It has been pointed out that the solution should support dynamic registration 
of clients during runtime (i.e., late after start-up time). It should be 
possible to register new clients even if the server doesn't know about them. In 
the proposal above, the service has up to three possibilities to select its 
broadcast targets (or combination of those):
1. select clients based on the order of subscription (limited expressivity)
2. select clients based on their generic names from a config file or deployment 
model (even possible for clients which are not known at configuration time if 
pattern-based matching is used)
3. select clients based on the additional information provided by the client 
via an optional register-method (see (d))

Original comment by klaus.birken@gmail.com on 20 Jun 2013 at 10:19

GoogleCodeExporter commented 9 years ago 
An additional proposal 4, extending proposal 3 and making session management 
shared is attached.

Original comment by scha...@itestra.de on 20 Jun 2013 at 11:15

Attachments:

GoogleCodeExporter commented 9 years ago 
In a conf call on 2013-06-28 with the developers of Common API C++ we decided 
to start with the solution described in comment #2. I.e. the Common API 
middleware will support the selective-keyword without any further IDL 
extensions. The reference part of the Franca User Guide will be extended to 
describe the semantics of the selective-flag thoroughly. 

The register-functionality of Common API will be available for review and tests 
to a larger audience. If it turns out that Franca IDL could support the use 
cases targeted here better by adding more IDL features, we can do this in a 
second step and learn from the actual implementation by Common API. The 
corresponding reviews and discussions will be done in the GENIVI context. If 
you are not a GENIVI member and want to contribute nevertheless, pls add 
yourself to the cc list of this issue and participate in the Franca Google 
Group. 

The actual task which should be done for this issue is the extensions needed 
for the User Guide.

Original comment by klaus.birken@gmail.com on 1 Jul 2013 at 9:47

GoogleCodeExporter commented 9 years ago 
This is a task for updating the User Guide, switched milestone accordingly.

Original comment by klaus.birken@gmail.com on 1 Aug 2013 at 8:36

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 30 Jul 2014 at 8:34