Hi Fabio, I had a closer look at proxy and engine layer and like that very much. Is it correct that proxy is on top of engine and can be seen as an extension? Or better the engine does work without the proxy, right?
In current OData 2.0 library we have also something that is on top which is JPA processor and annotation processor. This looks similar to your proxy just because it is on top, all deal with annotations and should ease the use of library. Maybe it makes sense first to have a deeper look into the engine and what we just call the library. The first thing that came into focus of my interest is edm. Concrete com.msopentech.odatajclient.engine.data.metadata.* which is similar to org.apache.olingo.odata2.api.edm.*. Both is edm. Independent of client or server use case there can be at least one common edm interface. On server side there is a so called edm provider which realizes lazy loading (partial read of metadata). For server this is essential but for the client lazy loading sounds like not required. I am note sure but don't see a use case where a client reads partial metadata. So maybe we have one interface and two implementations for edm. One edm implementation is optimized for client and another one carries all the stuff a server needs. Another thing is the com.msopentech.odatajclient.engine.data package and serialization/deserialization. Server and client do require the same functionality. Your implementation is dom based and uses jackson for json and xml (correct?). We are using stax for xml and gson for json and all is event based. With a dom base approach we experienced issues (performance and memory consumption) in case of large metadata or data sets. Jackson for json and xml makes sense because of stax is not a good option for Android client use cases. Olingos data structure that a server has to fill is quite low level. Actually its just a hashtable. Maybe we can make use of data classes like ODataEntity of your engine code. If you simplify the module proposal I made then we have a client code on the left and a server code on the right side. Ideally client and server do have their own best fitting architecture and structure. In other words a separation between proxy and engine for the client still makes sense. The challenge is the middle part, we call it 'commons', which is used by client and server. My candidates are edm and serialization. Regards, Stephan [1] http://olingo.incubator.apache.org/doc/tutorials/AnnotationProcessorExtensi on.html On 12.02.14 13:48, "Fabio Martelli" <[email protected]> wrote: >Il 11/02/2014 17:19, Klevenz, Stephan ha scritto: >> Hi, >> >> I would like to start a technical discussion about a module proposal >>for OData 4.0 client and server library. >> >> Starting point is that we have an OData V 3.0 client (Eduards new >>contribution) and an Olingo client/server for OData 2.0. On following >>wiki page I did draw a picture to get some first view on structure and >>to find responsibilities for modules. The idea is to get the best out of >>all contributions. >> >> https://wiki.apache.org/Olingo/Olingo%20Module%20Proposal >> >> There is not so much explained. Feel free to ask, comment or discuss. >> >> Greetings, >> Stephan >> >Hi Stephan, I'm taking a look at the wiki page "Olingo Module Proposal". >I've just a consideration to point out. > >OData V 3.0 client is composed of two main modules: the engine and the >proxy. >These are two difference abstraction layers with different scopes, of >course. > >The engine is the low-level communication layer taking care of actual >REST communication and OData entity (de)serialization, exposing methods >to hook into the OData protocol for manipulating entities and invoking >actions and functions. It is there for Java developers that needs to >access underlying details of the OData communication protocol. > >The proxy converts any local change to POJOs and any local invocation of >annotated interfaces' methods into actual calls to the Engine layer. It >is thought for experienced Java developers which are familiar with >widespread Java Enterprise and / or Open Source technologies and prefer >to interact with OData services at a very abstract level (like JPA, more >or less). > >Of course, the proxy layer depends on the engine layer BTW each one can >be considered as a different client. > >May be it would be better to explain this concept into the picture. What >do you think? > >Best regards, >F. > >-- >Fabio Martelli > >Tirasa - Open Source Excellence >http://www.tirasa.net/ > >Apache Syncope PMC >http://people.apache.org/~fmartelli/ >
