Hi Olingo community, As you might have seen from mailing lists I have been working with the project titled Implement OData Json Metadocument Serializer/Parser and hoping to participate this years GSoC with Apache Olingo. With the immense help from Christian, I was able to come up with a draft proposal for this project. I really appreciate if you could spend some time, provide me some feedback so that I could improve on it.
[1] https://docs.google.com/document/d/1bUOfAevle7zXQ9DOD7EWHh147nRK0fDWxrywkd1RLGU/edit?usp=sharing Herewith I am including the feedback I received from Christian. OData Summary: The OData metadata is not only machine readable but also defined in a way that it is human readable. Services and Clients have to know about the protocol when they are implemented. This is why we provide a library which takes care of the protocol. This way a client or server can focus on the business logic. Detailed Description: I like that you understood the importance of a platform where no native XML parser is available. This is the case for Android development. But with version V4 there is a way in which clients can consume a payload which was requested with the odata.metadata=full header. But this causes each payload to become huge. To avoid this one can query the metadata once. Also there is already a released version of V4 which does not contain the JSON metadata document format. The current draft for the next released version does contain the new format. Scope: Very good. This sentence is very important. I would add that the scope should follow the draft version as there is no released version. Design server core lib: Perfect. That was what I was looking for! Design client core lib: I understand the current approach you documented and this is definitely a way to do it. Maybe we do not even need the SchemaDeserializer class as we use Jackson to deserialize the json document. so maybe annotations are enough in this case. This we will have to see. Implementation Approach: Unit test cases have to be provided within the phase where you implement code. So for example if you implement the JsonSerializer in phase 1 then I would expect that within that phase you also provide the unit tests for the serializer. The same goes for phase two where you implement the deserializer. Phase 3 should be reserved for documentation and integration tests only. We have an fit module where one can write such integration tests. You should also include some minor milestones within the phases. At least an estimate per big feature. For example you expect 3 days for entity types and complex types and another week for functions and actions. Community Presence: You can write there that we will schedule a video chat. Regards Kevin
