Hi, On Wed, Oct 28, 2015 at 6:58 PM gerritbinnenmars <[email protected]> wrote:
> > > > Hello Pepijn,Good to start this topic. I have two questions:1. Could we > use the bundle version instead?2. Is the consequence of your last proposal > that the headers are included in the zip file? > Gerrit > 1) No. The bundle version does give an indication what is changed (e.g. a major version update implies that a is a major update in one of the provided services), but because a single bundle can have multiple provided and consumed services the bundle version on it self does not give enough information. 2) No. What I was thinking about is providing a service descriptor for every services. Currently these descriptors are created by hand, but we are already working on generating them from a IDL (e.g. Apache Avro). Note that this has a focus on remote services. If we want to support all services I expect we should generate descriptors from c header files during building. Because this will then be done build time, we have a lot of freedom choosing a appropriate parser technology. The idea behind the descriptor files is that they are easy parse-able without including a lot of dependencies, so keeping the footprint to parse this in Celix low. As an example the foo method in descriptor form is: foo(DD)V which should be recognizable for people with a Java background. Essential is that in such a format single characters can be directly treated as tokens. Hopefully this makes lhe last option a more clearer. Greetings, Pepijn > > Verzonden vanaf mijn Samsung-apparaat > > -------- Oorspronkelijk bericht -------- > Van: Pepijn Noltes <[email protected]> > Datum: 28-10-2015 12:23 (GMT+01:00) > Aan: [email protected] > Onderwerp: [DISCUSS] Service versions & semantic versioning > > Hi All, > > I like to discuss how to handle service versions in Apache Celix. > > To start of, I like to shortly review how service versions are handled in > the Java OSGi frameworks: > In Java, services are versioned by their java interface package version. > The OSGi framework will automatically select services you can resolve as > result of an package import statement. This is done using semantic > versioning. > The reasons this is possible is because Java has runtime type information > (RTTI) available. > > Apache Celix is based on the OSGi specification (written for Java) and > Celix has been been following the Java OSGi API as much as possible. > But because C has no RTTI, there is currently has no way to determining the > version of a service. This can result in very problematic bugs in > applications when (note not if) services will change/update. > > To make this problem more clear, consider the following, version 1, service > : > > struct example { > void (*bar)(double a, double b); > }; > > Also consider a version 2 of this service: > > struct example { > void (*foo)(double a, double b); > void (*bar)(double a, double b); > }; > > If the provider was compiled with version 1 and the consumer with version > 2, when the consumer tries to invoke bar it will invoke foo instead. And > currently there is no runtime information present to detect and prevent > this. > Also note that with the current solution of services, adding a method > before an existing method or reordering existing methods must result in a > major version update. > > IMO The primary feature Apache Celix delivers is (dynamic) modularity for C > applications. One of the key aspect of modularity is the ability to handle > different versions of services/interfaces. I think Apache Celix should > deliver a solution for this. > > > In this thread I would like to discuss how we can tackle this problem. I > already gave this some thoughts ,so I will start with listing some options > > Option 1. > Add a version / version range argument when registering services and > looking up services. This will break API with OSGi spec and does not > improve the situations where major update of the service version is needed. > > Option 2. > Add a version / version range argument to the dependency manager API. This > does not break the OSGi API (OSGi assembly). But also does not improves > when major updates are needed. > > Option 2. > Change how we use services. Instead of directly using struct, use a more > elaborate/opaque date type to support some run-time information (e.g. > version, provided method names, consumer method names) combined with some > marco magic to keep performance optimal. > This could work but I do think this breaks the simplicity approach we have > with Apace Celix. It does offer a solution to handle versions and also > improves support for service evolution. > > Option 3. > Add runtime information by parsing the services headers. > With remote services we already starting using descriptor files which > describes services. This makes it possible to runtime reason about services > and the differences between provided and consumer service. As result in > remote services there is already more flexibility to changes in the > services. This could also be done with local services, but then we must > parse the C header files. > This will support version info and improved support for service evolution. > I think is a very interesting solution, but a complex one and with > considerable effort to achieve. I would push Apache Celix to the next > level, meaning interface/service RTTI support for C. But is this something > we want / aspire? > > If anybody has some remarks, additional ideas/options or preferences for > the already mentioned options I would like to hear them. > > Greetings, > Pepijn >
