I see an important third category: clients that need to have the exact property types AND want payloads that are as minimal as possible.
For these use cases odata.metadata=full is not a feasible choice, so the client library has to access $metadata. Please design for this important use case. -----Original Message----- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Thursday, 13. February 2014 17:12 To: dev@olingo.incubator.apache.org Subject: Re: [DISCUSSION] Module Proposal OData 4.0 On 13/02/2014 16:52, Handl, Ralf wrote: > 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. With JSON light, there are different flavors of JSON data; with ;odata=fullmetadata (V3) or ;odata.metadata=full (V4) field types are returned as annotations alongside with actual values. What I am saying below is that current ODataJClient implementation relies upon such annotations for determining the correct property type; when such information is not available (because less details were requested to the service) sensible default types are used - most times just Edm.Integer or Edm.String. We took this design decision to leave the choice to the end user: if more precision is needed, full variants should be used, otherwise less verbose options are available. > 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. Exactly: this is specific for V4 and is reported as "$metadata service": http://docs.oasis-open.org/odata/odata/v4.0/cos01/part3-csdl/odata-v4.0-cos01-part3-csdl.html#_Toc372794056 Regards. > -----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/
