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 rajith77@gmail.com designates
 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACL1BnCdJpMC_SpK0TbGxQfJC0T0cNJmZKtfvZ3+M3qYpktH5g@mail.gmail.com>
References: 
 <CACL1BnD7ORaNnyjUUXqctDGo8J7ut0Nd91jn97dQw0hUu+=-rg@mail.gmail.com>
	<515044DD.5050809@redhat.com>
	<CACL1BnCdJpMC_SpK0TbGxQfJC0T0cNJmZKtfvZ3+M3qYpktH5g@mail.gmail.com>
Date: Mon, 25 Mar 2013 10:34:40 -0400
Message-ID: 
 <CA+M2Xzu2qU0bTqxb+nDNQKom6ohiF_gsJuGz4CB4wv9JHUOnOg@mail.gmail.com>
Subject: Re: RFC: new routing functionality for messenger
From: Rajith Attapattu <rajith77@gmail.com>
To: proton@qpid.apache.org, users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1

For starters I would copy this email to the user list.
(In the future we should post things like this to a more wider
audience, especially if we are looking for feedback based on real
world use cases.)

I actually like the minimalistic approach you've taken here. It works
well in an embedded context.
Support for regex will be a welcome addition.
I don't think we should bother with a config file for proton. To me
it's neither here nor there. Let the application developer or the
deployment folks who use the proton based application worry about it.
As both you and Ted pointed out, a more sophisticated routing
capability is best achieved outside the scope of Proton.

Regards,

Rajith

On Mon, Mar 25, 2013 at 9:30 AM, Rafael Schloming <rhs@alum.mit.edu> wrote:
> On Mon, Mar 25, 2013 at 8:36 AM, Ted Ross <tross@redhat.com> wrote:
>
>> I generally like this translation facility, though I'll need to think
>> through some use cases to make sure there's sufficient capability in the
>> matching and substitution.
>>
>
> I would definitely appreciate some more feedback on this area. I think some
> real world usage will help us out. I struggled with various options here. I
> didn't want to add a dependency onto a regular expression library without
> at least some kind of fallback as I think this functionality is going to
> end up being too useful to be optional.
>
> There are a number of public domain regular expression libraries out there
> (e.g. t-rex) that are basically designed to be small enough and simple
> enough to be sucked into a codebase wholesale for when you can't afford an
> external dependency. I considered grabbing one of those, but I also wasn't
> 100% sure that full on regex was the best/only option here. There is
> something nice and simple about being able to say route("*", "my-uplink")
> as opposed to writing a fullon regex.
>
> I can see possibly even wanting to support multiple syntax options
> eventually, but for starters I decided to keep it simple. I wrote a very
> small glob style matcher with substitution. It's roughly 100 lines of code
> and should work on any platform. I'm entirely open to replacing this with
> something a real regex library if we want or something else entirely, I
> just wanted something simple/portable to start with so we could actually
> play with the functionality and learn a bit more about what is appropriate.
>
>
>> I question the value of having this as part of the API.  It seems to me
>> that the Messenger routing table should be part of the configuration of a
>> system (i.e. in a place like /etc/qpid/messenger/, or the Windows Registry,
>> etc.).  Eventually, it might be desirable to have an address translation
>> service that can be accessed remotely.  I guess I see this translation as
>> being not the concern of the application, but more of the deployment of the
>> application.
>>
>>
> Initially I was actually going to add the functionality via some kind of
> configuration file as you say. I have a similar conceptual view of the
> functionality as you describe, i.e. it really should only be used as part
> of the deployment/configuration of the messenger, not part of the
> "application work" portion of the API. I ended up going this route for two
> reasons (no pun intended). For starters it was a bit more expedient as I
> didn't have to write some kind of file format parser, but the second, and
> perhaps more important reason, is that I wasn't sure of the implications of
> adding dependencies onto files/file systems. I want messenger to be usable
> from embedded devices that might not even have a file system, so I figured
> it would be safer to offer as a pure API. I do think it would be
> appropriate to layer some kind of system integration on top of this API
> just as you describe.
>
> --Rafael

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