Hi, again, I would like to do this conversion within a branch. First, because I would like to keep the current version until the new code is tested and stable and second because I am not yet 100% convinced about some of the design decision
* Singleton instance JAX-RS resources: AFAIK a requirement for using the Whiteboard pattern, but would also require to implementations to be thread save, something that is not necessary when using WebFragments. * RDF Viewable: Generally a good idea, but I would like to see some more examples of Freemaker Templates that use LDPath to render data available in RDF Graphs. I am also not convinced that the RDF Viewable stuff is so much better as defining the model as Java classes especially for those things where the data are not yet available as RDF data. WDYT Rupert On Tue, May 28, 2013 at 9:02 AM, Fabian Christ <[email protected]> wrote: > Hi, > > I understand Enrico and I think his big picture is valid. From the > discussion I see that we may have to work on our commons layer and > simplify that one. > > I see that Reto is pointing a lot on the use of those legacy > technologies. Work has started to remove them but this was not adopted > completely, yet. Defining a slim commons-2.0 sounds like a reasonable > approach to me. Having a sound definition of how things should work in > commons, we could plan for a sprint to adapt to the new commons in one > step. This would clean our code base and bring everything back on the > same level. > > Best, > - Fabian > > 2013/5/27 Reto Bachmann-Gmür <[email protected]>: >>> >>> I can also not see any of such issues. If someone wants to make major >>> changes to commons ... open a branch; implement the change; port some >>> components to give examples on how the new structure should look like >>> and agree on it within the community; upon acceptance give the >>> developers time to adapt their components to the new structure; merge >>> the new things back into trunk. >>> >> >> I'm not sure why you think creating branches would help. >> >> Example of pervasive legacy technologies usage include: >> - Non RESTfull Http Endpoints: The technologies to create semantic RESTfull >> services (i.e. services that can be consumed by client having nothing but a >> singe entry URI and understand mime types and ontologies) is there. It is >> exemplified and supported by archetypes, yet most of our code still has >> tightly coupled HTML interfaces. >> - Using Jersey specific classes: From my understanding of the discussions >> on the list there is a consensus that we should write our code so that it's >> portable across Jax-Rs implementations. The code to support things like >> multipart form without jersey dependencies has been in trunk for a while. >> - ServletContext to access services / communication between components. We >> could have a branch where this ugly hack is no longer available, but doubt >> this would be incentive enough for people to remove this stuff. >> - Use of some scattered around ontological terms from non-standard >> ontologies hardcoded in some java. >> - Whiteboard pattern for JAX-RS resources: It's there, still most code is >> using the WebFragements >> >> Stanbol is currently missing it's goal of providing RESTfull services and >> the size of commons also affects the re-usability as OSGi components. An >> approach would be to define a slimmed down "commons 2.0" designed to >> enforce a design that leads to the creation of Semantic RESTfull services >> and that comprise a smaller set of library so that Stanbol can more easily >> be run within any OSGi application and with any JAX-RS implementation. If >> we decide to go this way we could set a timeline to phase out commons 1.0. >> This would be more work than just cutting out some components but this >> takes into account that the size of a code base isn't the main criterion >> for it's maintainability. >> >> Cheers, >> Reto > > > > -- > Fabian > http://twitter.com/fctwitt -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
