You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/07/12 23:56:39 UTC
Re: Datacoding/Alphabet issue in SMPP
First, sorry for my late reply...
I think I found a good way to provide the data coding.
If we do
DataCoding.newInstance(dataCoding).value()
instead of
new GeneralDataCoding(false, true, MessageClass.CLASS1,
determinedAlphabet).value()
the user can choose between all possible data coding values. This would be
much more flexible.
I wonder if we also should still support the alphabet option or whether we
should use
DataCoding.newInstance(dataCoding).getAlphabet()
instead, to determine the alphabet..
What do you think?
Will have a deeper look into it tomorrow...
Best,
Christian
On Tue, Feb 7, 2012 at 3:08 PM, andrer <ar...@gmail.com> wrote:
> I've had some more time to study both the jsmpp and Camel-smpp code.
>
> The way Camel-smpp abstracts the data coding by using an Alphabet property
> and then deriving a datacode value by using a hard coded Message
> Class(class
> 1) restricts the possible datacoding values one can send to an smsc. (I am
> referring to the SmppSubmitSmCommand class in particular).
>
> For example, for the Clickatell smsc provider they would like me to send a
> datacode value of 0. With camel-smpp I can set the Alphabet property to 0,
> but the resulting datacode value will be 17, because it is derived from
> "GeneralDataCoding(false, true, MessageClass.CLASS1,
> determinedAlphabet).value())". If you unit test that line of code with the
> available Alphabet values you will see what I mean.
>
> So for me to be able to send a 0 to Clickatell, I would need something like
> "GeneralDataCoding(false, false, MessageClass.CLASS0,
> determinedAlphabet).value())".
>
> I think in order to provide an abstraction for the data coding, you will
> need to provide configuration properties for all the parameters in the
> GeneralDataCoding constructor. It would also be nice to have a way of
> overriding this abstraction and allow one to explicitly set the datacoding
> to a particular value(like my earlier requirement for a value of 245).
>
> I hope I am making some sense here :-) .
>
> I am still very impressed with the Camel project and the camel-smpp
> component has simplified our smpp solution by a huge amount.
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Datacoding-Alphabet-issue-in-SMPP-tp5281005p5463217.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Datacoding/Alphabet issue in SMPP
Posted by Christian Müller <ch...@gmail.com>.
Opened an issue to track this:
https://issues.apache.org/jira/browse/CAMEL-5455
Best,
Christian
On Thu, Jul 12, 2012 at 11:56 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> First, sorry for my late reply...
>
> I think I found a good way to provide the data coding.
> If we do
> DataCoding.newInstance(dataCoding).value()
>
> instead of
> new GeneralDataCoding(false, true, MessageClass.CLASS1,
> determinedAlphabet).value()
>
> the user can choose between all possible data coding values. This would be
> much more flexible.
> I wonder if we also should still support the alphabet option or whether we
> should use
> DataCoding.newInstance(dataCoding).getAlphabet()
>
> instead, to determine the alphabet..
>
> What do you think?
> Will have a deeper look into it tomorrow...
>
> Best,
> Christian
>
>
> On Tue, Feb 7, 2012 at 3:08 PM, andrer <ar...@gmail.com> wrote:
>
>> I've had some more time to study both the jsmpp and Camel-smpp code.
>>
>> The way Camel-smpp abstracts the data coding by using an Alphabet property
>> and then deriving a datacode value by using a hard coded Message
>> Class(class
>> 1) restricts the possible datacoding values one can send to an smsc. (I am
>> referring to the SmppSubmitSmCommand class in particular).
>>
>> For example, for the Clickatell smsc provider they would like me to send a
>> datacode value of 0. With camel-smpp I can set the Alphabet property to 0,
>> but the resulting datacode value will be 17, because it is derived from
>> "GeneralDataCoding(false, true, MessageClass.CLASS1,
>> determinedAlphabet).value())". If you unit test that line of code with the
>> available Alphabet values you will see what I mean.
>>
>> So for me to be able to send a 0 to Clickatell, I would need something
>> like
>> "GeneralDataCoding(false, false, MessageClass.CLASS0,
>> determinedAlphabet).value())".
>>
>> I think in order to provide an abstraction for the data coding, you will
>> need to provide configuration properties for all the parameters in the
>> GeneralDataCoding constructor. It would also be nice to have a way of
>> overriding this abstraction and allow one to explicitly set the datacoding
>> to a particular value(like my earlier requirement for a value of 245).
>>
>> I hope I am making some sense here :-) .
>>
>> I am still very impressed with the Camel project and the camel-smpp
>> component has simplified our smpp solution by a huge amount.
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Datacoding-Alphabet-issue-in-SMPP-tp5281005p5463217.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>