>> ...so, what about defining only an "conversion interface" in the Sling >API, limit it per >> javadocs to support only a fixes list of types and conversions, and start >with providing >> an own implementation in a new bundle based on what is in jcr.resource >today... > >+1 on having our own API while the OSGi one stabilizes, and maybe we >can already use the Felix implementation that you mention underneath? > >Temporarily forking that Felix code in Sling is ok and would make it >easier to control updates to the parts that we use, without depending >on Felix releases of that module.
in my pov our conversion API should be much simpler than the OSGi one, which in the current draft supports a lot of extra functionality like custom rules, copying etc. we should limit the scope of the interface to what is needed for valuemaps. so our use case is not exactly the same as the OSGi use case which has a much broader scope. for the impl it would be easier to start with what we have in jcr.resource today, but we could also fork the code and embed it in our own impl bundle until it is released if we think this makes more sense in the long run. forking and syncing with further updates in felix makes additional effort. independently of the way we choose we need a good set of unit test coverage of the valuemap-related conversions we want to support, so it's easy to switch the implementation later. stefan
