| [lyo-dev] Design / implementation questions |
Hi Lyo Dev, I have been playing around with the OSLC client for a week or so, and now I have some design / implementation questions. I fully understand that Lyo is targeting generic OSLC and not some specific tool, but I will relate to Jazz tools because these are the OSLC tools that we are working with. Q1 – Configuration vs Design decisions Some of the usage of inheritance (e.g. by extending a subclass) implicit requires the Lyo OSLC library users to take design decisions. A good example is that the JazzFormAuthClient extends the OslcClient – a construction that does not work well if you have form based authentication but want to use OAuth during future API calls (and therefor would need a variant of JazzFormAuthClient that extends OslcOAuthClient) In a real life scenario we as developers of solutions really would like to be able to configure the client behavior during execution time, since our customers set-up of their OSLC enabled server is not always known at design time. Example of configuration parameters: - Form based login vs Basic Authentication - OAuth vs Session based access The combination of these 4 options would requires several specialized classes. Have I misunderstood something about the underlying principles here? Even if my question is Jazz related is quite easy to image that other tool providers will provide the similar capabilities and thus require similar solutions. A solution could be that the OslcClient instead uses features provided by the OslcOAuthClient class (e.g. uses instead of inheritance) and that a (not yet existing abstract class) JazzClient class uses services provided by a JazzFormAuthClient. Q2 – Adding new resources RQM is providing both OSLC and an proprietary REST based API. As the QM specs evolve one can suspect that the proprietary API will disappear, but with the current solution there is a need to mix both OSLC calls and RQM REST API calls to create a real-life application. It is possible to mix an OSLC call with a RQM REST based called sharing the same HttpClient (thus implicit sharing cookies, session etc). So therefore we have the need to add some RQM REST API resource types (XML) capabilities to the existing OSLC QM resource types . The constructor of the OslcClient class internally creates the Wink application (and registers a hardwired list of providers) so I cannot clearly see how this could be done. As a remedy solution the OslcOAuthClient::getResource method seems to create a new Wink application for each resource request to manipulate the registered providers. So my question is simply how can I add RQM REST specific resources to the same client implementation that also knows how to handle OSCL resources? (would like to avoid the recreation of the Wink app for each request) Q3 – Exception/Error handling strategy At a first glance the method OslcClient::getResource(final String url, final String mediaType) throws IOException, OAuthException, URISyntaxException seems to be able to throw 3 different exception types. But after some examination it turns out that the code statements in the method is throwing 0 exceptions. (the throws clause is required because the overlaid method in the sub class OslcOAuthClient requires them – related to Q1) The Apache Wink library seems to be implemented using a “exception less” principle and instead rely on HTTP status codes and HTTP messages. Is this strategy also intended for the Lyo client implementation? Q4 – Resources definition in client In the client project there are core, cm and qm resources defined (in the package org.eclipse.lyo.client.oslc.resources) Should they not be contained in an separate library (e.g. jar) so that the same definition can be use both client and server side? |