Please excuse my ignorance, but why is metadata not needed on the client to parse responses to GET requests? JSON numbers may be Edm.Decimal, Edm.Float or Edm.Double, no difference in payload. And JSON strings may be any of the other Edm primitive types, also no hint in the payload as to what Edm type the property has.
Regarding lazy loading: if $metadata has Edmx:References to other CSDL documents, lazy loading might be of interest because you need to load the referenced documents only when actually parsing a response that uses a type from the referenced document. Another (future) use case is accessing portions of $metadata via the Metadata Service located at ~/$metadata/ (note the trailing slash); this might be more efficient for really large models. -----Original Message----- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Thursday, 13. February 2014 14:25 To: dev@olingo.incubator.apache.org Subject: Re: [DISCUSSION] Module Proposal OData 4.0 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/AnnotationProcessorExtension.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/java/com/msopentech/odatajclient/engine/utils/DefaultDOMParserImpl.java [5] https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/java/com/msopentech/odatajclient/engine/utils/AndroidDOMParserImpl.java?source=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/
