Hi Hugo,

Thanks for bringing this up and sharing your views on this.

I will share mine here and the possible ways to address it in ODL with its current architecture / design / principles.
We should certainly be able to come up with some clean design around this.

To begin with, as we all understand, the OVSDB mechanism is essentially a DB + JSON-RPC transport.
With OpenVSwitch defining its Schema for the tables that reside on the switches.
Any 3rd party / vendors can add extensions to the table or have entirely different set of schemas all together but just
retaining the OVSDB's transport mechanisms intact (as defined in http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6).

With that in mind, I started to reorganize our current OVSDB code into Library & Plugin.
As per my definition :
1. Library takes care of ONLY the generic OVSDB transport and DB mechanism
2. Plugin takes care of the provided services (such as Add bridge, add port, configure with tunnels, vlans, etc...).
(Will soon move them into 2 different OSGi bundles)

Hence to have keep with the separation of concerns principles, the Library development must NOT worry about any of the service requirements
and should just get the draft (http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6) implemented exactly as per the spec
(without having to worry anything about the hard-coded table structures : such as Bridge, Port, etc...). But, completely Schema driven as we
discussed yesterday. Hence when we talk about the OVSDB library development, there are no confusions on extensions or service provided.
It will just not worry about any of those & the only concern of this library is to handle maybe multiple versions of OVSDB transport draft (if any).

It is the plugin layer where the idiosyncrasies of various vendor implementations and the provided services come into play.
So, we have multiple ways to handle the extensions as well.
Take an example of a simple switch that uses the ovsdb mgmt mechanism. So, it is reasonable to provide services like the bridge creation,
port addition, etc... and have a plugin named OpenVSwitch plugin (which makes use of the OVSDB library) and can infact define this user facing
services (such as the existing ConfigurationService & InventoryService).
Any "extensions" provided by the vendor can be handled as the parent-child relationship as you mentioned (or) the vendor can come up with
his own plugin which is essentially a "fragment" bundle which attaches to the OpenVSwitch plugin (or) the vendor can come up with his own
plugin all together which doesnt share anything with the OpenVSwitch plugin & can expose its own services in its own way.

With any of the above Plugin choices, all of them will make use of the exact same OVSDB library that is the heart of the communication between
the Controller and the ovsdb-server agent.

So, as a first step, we can try and get this generic Library to be implemented, while we can work on the plugin architecture for such an extension.
Just my 2c.

Thanks,
Madhu