Thanks, will do. -----Original Message----- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Thursday, 13. February 2014 17:58 To: dev@olingo.incubator.apache.org Subject: Re: [DISCUSSION] Module Proposal OData 4.0
On 13/02/2014 17:43, Handl, Ralf wrote: > I see an important third category: clients that need to have the exact > property types AND want payloads that are as minimal as possible. Such clients seem not afraid to download and parse the metadata payload upfront, though :-) > 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. Ok, it seems we have an enhancement request, here: why don't you fill an enhancement on JIRA about this, once the ODataJClient code will actually be imported? Regards. > -----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/
