Hi all, see also my replies inline and to all not replied: +1 ;o)
On 13 Feb 2014, at 14:24, Francesco Chicchiriccò <ilgro...@apache.org> wrote: > >> 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). We also experimented with Jackson for JSON parsing and it is really fast. But we used the streaming / event based approach from the Jackson library which seems faster then the annotation based. So I agree with using the Jackson library in general ;o) Probably we can also use JSR-353 (Java API for JSON Processing) in combination with Jackson. So we will be flexible which implementation is used at the end. Kind regards, Michael
smime.p7s
Description: S/MIME cryptographic signature
