Re: C++ Plugin modules

[Gordon Sim <gs...@redhat.com>]

On 06/28/2013 07:46 PM, Andrew Stitcher wrote:
> On Fri, 2013-06-28 at 17:03 +0100, Gordon Sim wrote:
>> The Protocol/ProtocolRegistry and the ObjectFactory (two different
>> things) introduced a way of extending the existing monolithic broker.
>> I'm not sure its entirely fair to say there are two different approaches.
>>
>
> I didn't make myself clear enough - when you introduced these
> abstractions you still left the old non-abstracted code - so we now have
> to understand both the old way and the new way.

Your point was clear enough, I just don't agree with you.

The difference between the 0-10 and 1.0 protocols and implementations is 
far, far bigger than the minor differences resulting from the fact that 
the 0-10 code does not implement the Protocol abstraction. (At present 
that abstraction is for _additional_ protocols, since in part it still 
assumes the existence of 0-10).

By being a plugin, some valuable abstractions were forced onto the 
development of 1.0. Had the Protocol abstraction not been introduced, I 
believe the overall 'cognitive burden' would be greater, not less.

As I said, I think it would be useful to make the 0-10 support optional.

However if the burden of fixing _all_ the problems on the past is always 
added to the burden of developing a new feature we would never move 
forward. The fact that 0-10 was so ingrained throughout the codebase 
meant that a piecemeal approach was the only way anything would happen. 
That in turn means that some way of limiting the scope of changes has to 
be found, even if that falls short of the ideal picture.

(Of course, a balance always needs to be struck and striving for the 
best that can be achieved is always important. I just don't accept that 
means that an imperfect step forward is worse than no step at all).

>> The existing 0-10 support could - in my view, should - eventually be
>> made optional. We need _more_ modularity.
>
> Precisely, however just introducing a new abstraction actually makes
> things worse in the short term though because there are now more
> concepts to understand.

Again, I disagree.  By introducing a new abstraction the door is opened 
to reuse that abstraction for other use cases. It also more clearly 
shows the way forward for the future, even if not all the code is 
aligned in that direction yet. Yes, there is a new concept to 
understand, but that does not in itself mean things a worse. (The 
previous absence of any clear concept could be seen as a problem, now 
fixed).

I believe in evolutionary steps towards something better _and_ more 
complete, rather than waiting until it can all be done in one step (an 
approach which in my experience tends never to deliver). Progress is 
progress even if there remains a long way to go.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org