Fabio, Francesco, others, [1] is the package for the Olingos EDM V4 interfaces. Do you think they are usable for the V4 client? As said before I see two kind of implementations, one for server and one for client. If we could use this interfaces commonly then other components relying on EDM could become re-useable as well.
Regards, Stephan [1] https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.git;a=tre e;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo/odata4/co mmons/api/edm;h=01bbfc90c49208164364326c2b83566990d174ec;hb=HEAD On 13.02.14 14:51, "Fabio Martelli" <fabio.marte...@gmail.com> wrote: >Hi Stephan, your analysis is good, thank you. >Francesco (extremely faster then me) seems to have answered to all the >questions. >@Francesco: thank you for details and clarifications about >(de-)serialization stuffs. > >My +1 to the latest proposal about middle part ('commons') refactoring. > >Best regards, >F. > >Il 13/02/2014 14:24, Francesco Chicchiriccò ha scritto: >> Hi Stephan, >> see my replies inline. >> >> Regards. >> >> On 13/02/2014 13:57, Klevenz, Stephan wrote: >>> 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? >> >> Correct. >> >>> 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. >> >> Agree, this seems definitely reasonable. >> >>> 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. >> >> About metadata, think that in ODataJClient any request but invoke does >> not need metadata to work; moreover, metadata don't need to be written >> on client side, but only parsed. >> This to confirm that IMO we should find a way to retain a common part, >> given the different usage that client and server make of metadata. >> >> As you've already seen, we use Jackson XML [2] for parsing metadata: >> we found it very efficient, flexible and unbelievably fast. >> Moreover, consider that we have already implemented the V4 metadata >> parsing in the ODATA_4 branch (the one which is actually being donated). >> >>> 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. >> >> The current V3 implementation works well with Android (there is also a >> working sample [3]) and uses different DOM implementations for the >> desktop [4] and mobile [5] use cases. >> Anyway I am currently updating the Atom parser (still at GitHub, >> waiting for the code to land to olingo4 repo) and I am realizing that >> Jackson XML [2] is, as you suggest above, probably the best option: >> >> * PROS: performance, uniformity with metadata handling, removal of >> "special" Android treatment [5] >> * CONS: need to rewrite from scratch the current Atom parser :-) - >> but I've already started this work >> >>> 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. >> >> +1 >> >> Regards. >> >> [1] >> >>http://olingo.incubator.apache.org/doc/tutorials/AnnotationProcessorExten >>sion.html >> [2] https://github.com/FasterXML/jackson-dataformat-xml >> [3] https://github.com/Tirasa/ODataJClientOnAndroidSample >> [4] >> >>https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/j >>ava/com/msopentech/odatajclient/engine/utils/DefaultDOMParserImpl.java >> [5] >> >>https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/j >>ava/com/msopentech/odatajclient/engine/utils/AndroidDOMParserImpl.java?so >>urce=cc >> >>> On 12.02.14 13:48, "Fabio Martelli" <fabio.marte...@gmail.com> 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/ >
