search

anuragraghavan / franca

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

Missing combined aspects in Franca Deployments #93

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The Deployment model allows to define properties for each Franca language 
element, but each language element has several aspects how it can be looked at.
Example:

specification org.genivi.commonapi.dbus.deployment.deployment extends 
org.genivi.commonapi.core.deployment.deployment {
    for unions {
        VariantType: {CommonAPI, freedesktop} (default: CommonAPI);
    }

    for arguments {
        ArgVariantType: {CommonAPI, freedesktop} (default: CommonAPI);
    }}

This specification specifies additional properties for unions and method 
arguments, but it is not possible to provide specifications for only arguments 
which are unions.
If ArgVariantType is used in a deployment definition, it is possible to use it 
for any argument type, even Strings or integers.
If VariantType is used all unions of a certain type are affected in this 
interface instance.
It is not possible to define a property in a deployment definition which is 
only valid for a method argument that is of type union. Or in other words, 
there is no way to make Franca deployment validation complain if ArgVariantType 
is used for arguments which are not of type union and where it is not 
applicable (like String, Int, ...).

There are a lot of similar usecases, e.g. String encoding or maximum array 
length, which could be defined per argument.

Proposal:
The current Franca deployment model should be extended to allow more specific 
specifications to help identify wrong/superfluous properties in deployment 
definitions.

Original issue reported on code.google.com by bathe...@gmail.com on 26 Mar 2014 at 5:27

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 29 Jul 2014 at 9:41

GoogleCodeExporter commented 9 years ago 
In theory, we could think about implementing boolean expressions like

for unions & arguments { ... }

or similar. Some further analysis is needed to check the ramifications of this 
proposal. First thing that comes to mind is that the syntax of the example is a 
bit misleading (for unions and arguments could mean that the properties have to 
be available for both kinds of hosts, not for those hosts which match both 
aspects). But I guess we can come up with some better syntax for this.

Original comment by klaus.birken@gmail.com on 10 Nov 2014 at 1:20

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 25 Jan 2015 at 12:07

GoogleCodeExporter commented 9 years ago 
Postponed to 0.10.0 (concept and syntax are not yet clear).

Original comment by klaus.birken@gmail.com on 8 May 2015 at 8:25