Yes. I pick out one example:
https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/jav a/com/msopentech/odatajclient/engine/metadata/edm/v4/EntityContainer.java 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. Regards, Stephan 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.git;a=t >>re >> >>e;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo/odata4/ >>co >> mmons/api/edm;h=01bbfc90c49208164364326c2b83566990d174ec;hb=HEAD > >[2] >https://github.com/MSOpenTech/ODataJClient/tree/ODATA_4/engine/src/main/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/AnnotationProcessorExt >>>>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/ >
