Hi Christian,

I think that makes a LOT of sense. I am sort of surprised that they are mixed 
to begin with given the many differences in the specs and the fact the v4 spec 
is still evolving. I know it is a significant effort but one that will pay off 
moving forward. Thank you for taking this on.

Ted

----- Original Message -----
> From: "Christian Amend" <[email protected]>
> To: [email protected]
> Sent: Friday, February 6, 2015 10:01:37 AM
> Subject: [DISCUSS] Seperating V3 code from the V4 code
> 
> Hi all,
> 
> When working with the server part of the Olingo V4 library I came across the
> fact that there is a lot of V3 specific code within the commons module which
> is visible from the server perspective. This is because the client supports
> the consumption of V3 services as well as V4 services. On server side the
> main goal was to only support V4.
> This can be quite confusing as to which classes to use and defining which
> feature is working on client side or server side only.
> 
> So I would suggest we split the codeline at the current state and have two
> separate codelines. One for V3 functionality only and one for V4
> functionality only.
> The V4 codeline would contain a V4 client, a V4 server and the commons
> module.
> The V3 codeline would only contain a V3 client. No server and commons module
> there for the time being.
> 
> This would make it much easier to implement new features in the V4 codeline
> without introducing regressions with the V3 code. Also in my opinion the
> architecture would be easier to understand for developers. Also the code
> base could be significantly reduced by deleting all the forks between
> specification versions.
> 
> The ultimate goal would of course be a way to use a V4 and V3 library in the
> same Java Client. As of now a client developer has to specify which service
> he wants to consume anyway via a property. In the future this could be done
> via another ODataV3 object or so.
> 
> So WDYT? I hope for a lot of comments as this is a major refactoring!
> 
> Also I would volunteer to perform the refactoring if there are no objections.
> 
> Best Regards,
> Christian
> 

Reply via email to