Thanks. I assume that 'read/write scenarios' means handling ATOM/Json payload, not Edm (AFAIK client side doesn't need to serialize Edm). But it looks good to have common component to support reading&writing Edm too, so for both Edm and ATOM/Json payload, there will be : (1) object interfaces, (2) de/serializer interfaces(pluggable). correct?
-Challen -----Original Message----- From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] Sent: 2014年2月20日 23:26 To: dev@olingo.incubator.apache.org Subject: Re: [DISCUSSION] Module Proposal OData 4.0 to (1) - yes to (2,3) - Serialization/deserialization both is required on client and server side (read/write scenarios). Currently I am not sure if one implementation can server client and server needs. Currently I am experimenting with Jacksons and I am not sure if the mapping feature and a dom based serialization will work on server side. Main concern is memory consumption and performance. Streaming seems to be more efficient. No final decision yet. About pluggability: +1 Stephan On 20.02.14 14:40, "Challen He" <chall...@microsoft.com> wrote: >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:ilgro...@apache.org] >Sent: 2014年2月14日 19:35 >To: dev@olingo.incubator.apache.org >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/ma >> i >> 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ò" <ilgro...@apache.org> 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.g >>>> i >>>> t;a=t >>>> re >>>> >>>> e;f=odata4-lib/odata4-commons-api/src/main/java/org/apache/olingo/o >>>> d >>>> ata4/ >>>> co >>>> mmons/api/edm;h=01bbfc90c49208164364326c2b83566990d174ec;hb=HEAD >>> [2] >>> https://github.com/MSOpenTech/ODataJClient/tree/ODATA_4/engine/src/m >>> a in/ja va/com/msopentech/odatajclient/engine/metadata >>> >>>> 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/AnnotationProces >>>>>> s >>>>>> 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/sr >>>>>> c >>>>>> /main >>>>>> /j >>>>>> ava/com/msopentech/odatajclient/engine/utils/DefaultDOMParserImpl. >>>>>> java >>>>>> [5] >>>>>> >>>>>> >>>>>> https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/sr >>>>>> c >>>>>> /main >>>>>> /j >>>>>> >>>>>> >>>>>>ava/com/msopentech/odatajclient/engine/utils/AndroidDOMParserImpl. >>>>>>jav >>>>>>a? >>>>>> 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. > >-- >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/ >
