camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Ford <m...@massfords.com>
Subject Re: Advice for CAMEL-3476
Date Thu, 17 Mar 2011 03:48:51 GMT
I thought this was settled in the issue comments already. You haven't
raised any new points except the percentage of code devoted to the
consumer which I think is irrelevant. That code is only exercised when
the user provides the appropriate switches and it also may shrink when
Tracy refactors the component to share code between the SQS and SNS
components which were developed separately.

Also, steps 1, 2, 3, and 6 below are optional. Their execution depends
on whether you created the subscription with a SQS name as opposed to
a SQS ARN. I don't think it's fair to criticize having to make a call
to the server to create the subscription (step 4 below). I don't know
how else to do this apart from not supporting it at all like you've
proposed.

That said, I can't imagine more than a dozen people in the world will
use this component for either pub or sub so it's not that big of a
deal. I'll keep the google code project up if people crave this
functionality.

-- "Another guy"

On Tue, Mar 15, 2011 at 2:48 PM, Christian Müller
<christian.mueller@gmail.com> wrote:
> Hello dev!
>
> I would like to get an advice from your for [1].
>
> I would prefer to implement the AWS SNS component to "only" provide a
> producer (which sends notification to the AWS SNS topic).
> In my opinion, the user should be responsible to configure the subscription
> for this topic (outside of Camel with the Amazon management web console). If
> the user subscribe to an AWS SQS queue, he can use the AWS SQS component and
> poll this queue (already available since Camel 2.6.0).
>
> Another guy would like to make this subscription via Camel, which has in my
> opinion the following disadvantages:
> - The Camel SNS consumer acts like the Camel SQS consumer. It polls an AWS
> SQS queue. Therefore we have some code duplications and two different
> components which do the same thing.
> - It's only planned to make a subscription to an AWS SQS queue. If the user
> would like to make a subscription to HTTP, HTTPS, E-Mail or so, he has to do
> it still manually.
> - The subscription functionality will be the biggest part of this component:
> at startup:
>   1) Create the AWS SQS queue (mandatory web service call)
>   2) Query the queue ARN (mandatory web service call)
>   3) Provide the policy to allow the AWS SNS topic to write into the AWS
> SQS queue (mandatory web service call) --> For this, the user has to provide
> its own policy file in JSON format
>   4) Make the subscription from the AWS SNS topic to the AWS SQS queue
> (mandatory web service call)
> at shutdown:
>   5) remove the subscription (web service call if required)
>   6) remove the AWS SQS queue (web service call if required)
> - I have some bad feelings therefore (which I cannot express good) and I
> would like to provide a cleaner, easier to use and to maintain component.
> Also with the absence of functionality which may be only a few people use
> and a good alternative exists (Amazon management web console to make the
> subscription)
>
> What are your thoughts? Could you please comment this issue?
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-3476
>
> Cheers,
> Christian
>

Mime
View raw message