so this is what we are going to have(pls corrct me if I misunderstand anything): (1) A set of Edm object interfaces for both client & server (2) Edm deserializer interfaces for client (3) Edm serializer interfaces for server
based on the above, can we make de/serializer's implementation be pluggable? so that either client or server user can substitute their de/serializer for specific needs/optimization. thanks,-Challen -----Original Message----- From: Francesco Chicchiriccò [mailto:[email protected]] Sent: 2014年2月14日 19:35 To: [email protected] Subject: Re: [DISCUSSION] Module Proposal OData 4.0 On 14/02/2014 12:30, Klevenz, Stephan wrote: > Yes. > > I pick out one example: > > https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/mai > n/jav > a/com/msopentech/odatajclient/engine/metadata/edm/v4/EntityContainer.j > ava > > Entitycontainer.getEntitySet(String name) iterates over the list of > all entity sets. This doesn't work on server side. Server is > stateless, needs only one entity set for validation and can query this very > efficiently. > Conclusion: I like the api, but I want to exchange implementation. > > Can we agree on that EDM should get interfaces instead of classes? > Interfaces will enable us on creating multiple implementations. Definitely, +1. Regards. > On 14.02.14 10:35, "Francesco Chicchiriccò" <[email protected]> wrote: > >> On 14/02/2014 10:29, Klevenz, Stephan wrote: >>> 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. >> Hi Stephan, >> it seems that [1] is close to [2], except that [2] has subpackages >> for >> V3 and V4: it will require some work, but it seems that the suggested >> place is correct. >> >> Regards. >> >>> [1] >>> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-olingo-odata4.gi >>> t;a=t >>> re >>> >>> e;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo/od >>> ata4/ >>> co >>> mmons/api/edm;h=01bbfc90c49208164364326c2b83566990d174ec;hb=HEAD >> [2] >> https://github.com/MSOpenTech/ODataJClient/tree/ODATA_4/engine/src/ma >> in/ja va/com/msopentech/odatajclient/engine/metadata >> >>> On 13.02.14 14:51, "Fabio Martelli" <[email protected]> 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/AnnotationProcess >>>>> orExt >>>>> en >>>>> 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" <[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. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
