Stefan Seifert wrote > >>> ...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. >
Whatever we do, we should rather build utility (static) methods for the conversion or have a static way of getting the converter. Creating an OSGi service out of this is imho overkill. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
