Hi Rupert I'm fine with the branch as long as we reach a consensuns on the list on where we want to go and schedule a switch to the commons 2.0 branch. Otherwise I don't see how the speed of the effort of improving code quality and maintainability could keep pace with the growth of code and increasing of features.
* 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. > A resource class that's not thread-safe is quite smelly anyway. Do you know of any resource class that sets per-request field instead of passing the values as arguments to its private methods? Also while a new resource class instance for each request is the default the JAX-RS spec does not mandate this behaviour so relying on it is not consistent with portability. > * 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. > As we were using the viewable now we were typically not passing a plain value object to the Viewable but the Resource class itself, meaning that during rendering some of its methods got invoked and arbitrary functionality executed. Now even if we would use POJOs as plain value object and thus have a clean presentation between presentation and application logic we would still need a mechanism that can render this POJO encapsulated data in a machine readable format if we want it to be consumable as a REST service. RDFViewable solve both of these issues, once the resource method returns there can't be no more callback to the resource class [*] and all that can go wrong relates to the rendering of the data. Without any template the data can be rendered as RDF which is the foundation for a semantic REST API. I'm not sure myself if LDPathTtemplate is good enough. I hope they will add features like rdf:List support and sorting soon. But the important thing is not LDPathTemplate (we could easily add support for many templating languages) but the separation of root resources returning RDF and an optional machinery to produce HTML. Cheers, Reto * unless you're doing really weird stuff with virtual graphs > > 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 >
