Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5257DEC0.5060201@redhat.com>
References: <525574AE.6050008@redhat.com>
	<CACsaS946uJZsYTPQoY+p6XnS_dVyt7zPewbjchTvJ9Ys7g03vQ@mail.gmail.com>
	<52558D29.8010108@redhat.com>
	<CACsaS94Z2ehawK24tVoFFnN2PpYuBK3EgdYC6JnSRUCr+X3h1g@mail.gmail.com>
	<5256AD3A.7020904@redhat.com>
	<CACsaS94Lve5NjSDUnjXuOab0=QWH42faaueyS=6oPgiK4Mgw1A@mail.gmail.com>
	<5257CAE2.9090605@redhat.com>
	<CACsaS95=L7yfZPBMCaruyzQLce9W2BRHsY3hSi-6jXKo63j89w@mail.gmail.com>
	<5257DEC0.5060201@redhat.com>
Date: Fri, 11 Oct 2013 13:24:23 +0200
Message-ID: 
 <CACsaS96uticdbbbLSUWebJmEQxwL_bfr_4v1hjETqodjRcUy7Q@mail.gmail.com>
Subject: Re: Qpid Dispatch Router component
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=20cf301cbee44b5d1004e8755ce8

--20cf301cbee44b5d1004e8755ce8
Content-Type: text/plain; charset=ISO-8859-1

On 11 October 2013 13:19, Gordon Sim <gsim@redhat.com> wrote:

> On 10/11/2013 11:52 AM, Rob Godfrey wrote:
>
>> On 11 October 2013 11:54, Gordon Sim <gsim@redhat.com> wrote:
>>
>>
>>>
>>> Second, the code in Dispatch Router is in theory designed around a
>>> toolkit
>>> for building  AMQP 'containers' of different kinds, with the router being
>>> one such example (another might be a proxy focused more on enforcing ACLs
>>> at the edge). In theory this could be viewed as an API of sorts. However
>>> I
>>> think at this point its better viewed as a sensible desire for some
>>> internal structure and separation of concerns. A publishable 'API' is in
>>> my
>>> view some way off and would require a lot of work that would at this
>>> point
>>> distract from the main goal, which is to define the behaviour of the
>>> router
>>> and implement it.
>>>
>>>
>>>  This would be really cool... though I would hope/think this would lead
>> to a
>> spin-off new component for the toolkit rather than being part of Dispatch
>> itself?
>>
>
> That would make sense to me, though I think we should cross that bridge if
> and when we ever come to it. (E.g. if a new component emerges that wants to
> reuse some of the same codebase).
>
>
Yeah - that makes sense.


>
>   As such (and for the reasons you also allude to) I would think
>> this would not be a goal of Dispatch itself, but rather some sort of
>> stated
>> aim and guiding principle of the development.
>>
>
> To me, the focus has to be on demonstrating the vision (and proving it
> works and has value). The rest is just good programming practice (modular
> design, with minimal coupling and maximum cohesion).
>
>
+1


>
>   Going off-topic a bit I
>> guess... but would we see such a framework as having multiple
>> implementations (in different languages) or only in C?
>>
>
> Again, to me the language used is secondary to the goal of proving the
> concept with real, deployable software. I do think that the communication
> patterns on top of AMQP between routers should be very clearly spelled out
> to allow clones or alternative implementations following the same rules to
> be developed if anyone anywhere has the desire to do so.
>
>
>
Agreed on all the above :)

-- Rob


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

--20cf301cbee44b5d1004e8755ce8--