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
