The key advantage to doing away with two models is to make writing code that deals with both the topology and inventory models (which is nearly all code for OpenFlow) in Java reasonable to write. As it stands, you can only import one "Node" class in java via anything other than it's full class name with package and that results in really, really annoying code.
Also, the constant translation back and forth is a recipe for errors in program logic. --Colin On Mon, May 9, 2016 at 11:26 PM, Anil Vishnoi <[email protected]> wrote: > > > On Mon, May 9, 2016 at 2:42 PM, Robert Varga <[email protected]> wrote: > >> On 05/02/2016 11:52 PM, Abhijit Kumbhare wrote: >> > Hi folks, >> > >> >> [snip] >> >> > This will require some change by the dependent projects (some >> > modifications in the dependency declaration in the pom files) - however >> > it will be less change than a complete migration to the topology model. >> > *If you have any thoughts about the change - please provide your >> thoughts*. >> > >> > We inside of OpenFlow Plugin project like this change (as opposed to the >> > inventory to topology model migration change for which there were no >> > volunteers due to the effort and lack of obvious benefits). >> >> I have to disagree on the 'lack of benefits' part. Having aligned base >> models is critical for end user experience. The topology model is >> implemented by multiple SB plugins to expose exactly the same semantics >> as the inventory model. >> >> From modeling perspective, the inventory model is a strict subset of >> concepts expressed in the topology model. >> >> Keeping two models for the same thing is pure overhead from maintenance >> and interoperability point of view. >> > I don't really see any major maintenance and interoperability issues and > i believe once we move inventory model to openflowplugin, we avoid any > future issues as well. > If i weigh the benefit of removing these models and disrupting the > downstream projects Vs containing it within plugin with minimal > disruption, i don't really see any value in removing inventory models. > >> >> The inventory model must be eliminated if we ever hope to have any sort >> of consistence across SB plugins. This has been discussed and agreed >> multiple times, can we please stick to the plan? >> >> > I am not sure we can achieve 100% consistency across SB plugin, because > IMO we can't force any southbound plugin from using these inventory models > in future as well. > About sticking to the plan, sure we can, i am just throwing alternate > options, where we can manage this situation without doing any major > disruption and i don't really see any major issue with it. > > >> >> >> > >> >> Since there is a proposal to eliminate the OFP version-agnostic model >> (which is tied to topology via the new plugin), I think it would be very >> logical to attach the OFJ models to topology as a replacement and simple >> gradually desupport the inventory model -- old stuff works as long as >> old models do. >> > This looks like a middle path, but i believe it's bit long term > solution, but make sense to me. > >> >> Thanks, >> Robert >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/discuss >> >> > > > -- > Thanks > Anil > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
