Discussion:
AT&T plugin for WebSMS
Claudio Procida
2008-06-14 10:56:24 UTC
Permalink
Hi Michael,

did you make any progress with your AT&T plugin for WebSMS?

The current revision of WebSMS in the repository already provides the
new variables for US phone numbers:
+1 234 567 8901234
TO_CCODE => 1
TO_US_AREACODE => 234
TO_US_PREFIX => 567
TO_US_NUMBER => 8901234

Let me know if you need further assistance.
Best regards,
Claudio
Claudio Procida
2008-06-16 09:25:46 UTC
Permalink
Post by Claudio Procida
Hi Michael,
did you make any progress with your AT&T plugin for WebSMS?
The current revision of WebSMS in the repository already provides the
+1 234 567 8901234
TO_CCODE => 1
TO_US_AREACODE => 234
TO_US_PREFIX => 567
TO_US_NUMBER => 8901234
Let me know if you need further assistance.
Best regards,
Claudio
Thanks for adding the TO_US_ values. I will definitely need them.
Reading this message, I realize I may have been mistaken. +1 234 567
8901234 is too many digits, US is just +1 234 567 8901. I was under
the impression that TO_CCODE=1, TO_PREFIX=567, TO_NUMBER=8901, with
nothing for areaCode=234, but now I think I was mistaken.
Nevertheless, I do need to be able to break 5678901 into 567 and 8901.
yeah, don't mind that. I am verbose at times. Let's say then that:

+1 234 567 8901
TO_CCODE => 1
TO_US_AREACODE => 234
TO_US_PREFIX => 567
TO_US_NUMBER => 8901
I will also need to figure out how to get similar FROM_US_ values just
like the TO_US_ values you added. With AT&T-US, %USERNAME% is
actually the phone number, 2345678901. This value could also be
extracted from a cookie value or by regular expression from one of the
web pages.
Since the value of username may be everything, I would be reluctant to
add predefined variables that split the username in chunks.
If the sender's number is written into a server response, you can grab
it (in its entirety or by splitting it into the parts you need) into a
custom variable (see pugin syntax in the wiki[1] for further explanation
of the "vars" section).
This is my first exposure to JavaScript, so I'm a bit green. From the
plugin, do I have access to Phone._message.username? Is there a less
hackish way to do this?
The plugin is generally "static" code, it is just declarations, although
some hackery is possible.
Since it is executed in the context of the widget, you have access to
global objects like phone (the controller), widget and so on.
Caveat: this is not a recommended practice because plugins are not
guaranteed to be executed in the context of the Dashboard Widget (they
could be used in versions of WebSMS for other platforms -- e.g. Yahoo
Widgets, Vista Gadgets... -- as well).

IIRC, the author of the ETHZ plugin has heavily hacked the
availabilityCheck function (see sources). That is a good place to have
code executed.||
So this plugin seems to be more complex than any of the other plugins,
or maybe I'm not seeing all the power of the plugin architectrue. I
am currently getting the whole process to work using curl, then once I
know I have the right process I'll translate the curl commands to a
plugin. I started writing the plugin and quickly realized it was the
wrong way to go while I was unsure of the target process. Using curl
I got to the point once of being logged in to my account, at which
point I didn't have the next command(s) ready or I'm sure the whole
process would have succeeded. Then something reverted, and I haven't
been able to log in again, but I am close.
I am sure that the goal is nearer than you would expect. I suggest you
to read the documentation and examine the source code (which is
thoroughly commented) to understand how WebSMS works, and use one of the
existing plugins as a model (for example the tim.conf.js which is
probably the most complete one).
With curl, I've been using the -b/--cookie option and the
-c/--cookie-jar option (and I believe the cookie-handling is the
barrier to login). I'd rather just handle entire cookies than use the
plugin ability to handle individual cookie key/values--there are a lot
of cookies with a lot of key/values, and I'm not all that interested
in finding the minimum set that allow the process to procede. Am I
misinterpreting the cookie support you provide? Or else, using the
curl -b and -c options, what would be an appropriate place to store
the cookie file between commands (i.e. between plugin steps)?
Cookies are automatically handled for you by the WebSMSEngine. You
should not even care about that!
PS, this is probably beneficial for the list, and you're welcome to
post it.
With great pleasure!
Best regards,
Claudio

[1] http://websms.origo.ethz.ch/wiki/plugin_syntax
Claudio Procida
2008-06-17 07:17:34 UTC
Permalink
Howdy,
Of course it was a one-char typo in my curl commands that I was
overlooking. I've got the process working with curl commands. But
for the widget, the send neither succeeds nor fails, and I don't know
what it is doing. How do you usually go about debugging in the
widget? I've attached my progress so far--perhaps you would easily
spot a mistranslation from the curl commands (in the comments) to the
plugin syntax.
By enabling the debug mode of WebSMS [1] you will have server responses
printed to the Console, so you can easily compare them to the sources of
web pages that you visit manually with a web browser.

Another help is the use of "check" sections which you can use to detect
error conditions and to block the sending process as early as an error
happens.
The bad news is that I just realized AT&T's web page only allows
sending SMS to other AT&T subscribers, not any US number as I
previously thought, so it won't really even be useful to me when
finished.
It will be surely useful to so many people indeed!

I'm attaching a revised version where I extract the session ID used in
the login URL (It will probably work without, but as a general rule
WebSMS plugins should be "polite" and try to be as close as possible to
normal requests issued by a web browser).

Keep up the good work!

[1] Type in a Terminal window: defaults write
widget-it.emeraldion.widget.websms Debug -bool YES


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "WebSMS" group.
To post to this group, send email to websms-/***@public.gmane.org
To unsubscribe from this group, send email to websms-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/websms?hl=en
-~----------~----~----~----~------~----~------~--~---
Claudio Procida
2008-06-17 07:24:27 UTC
Permalink
Post by Claudio Procida
I'm attaching a revised version where I extract the session ID used in
the login URL (It will probably work without, but as a general rule
WebSMS plugins should be "polite" and try to be as close as possible to
normal requests issued by a web browser).
Keep up the good work!
Whoops, I've spotted another error.

The "charset" should be set to "utf-8" or left blank (since this is the
default).

If the charset is not declared correctly, the widget may get "undefined"
responses, though this should not be the case (it would happen for
example if pages were encoded with ISO-8859-1 and you did not set this
charset).

Please ignore the previous file.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "WebSMS" group.
To post to this group, send email to websms-/***@public.gmane.org
To unsubscribe from this group, send email to websms-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/websms?hl=en
-~----------~----~----~----~------~----~------~--~---
Michael Pederson
2008-06-18 06:25:00 UTC
Permalink
Claudio, thanks for your support through this process. This AT&T-US
plugin is my first contribution to open source software. All in all,
the plugin development process is really simple thanks to a great
plugin architecture. I spotted my last error within a few minutes of
turning on debug mode. The snags I encountered were all of the
missing-semi-colon variety.

It is functional for sending a text to myself. WebSMS has all the
pieces of the puzzle, then AT&T's service let me down. While I
originally thought this would allow me, as an AT&T subscriber, to send
texts to anyone, I didn't realize the AT&T web page only allows texts
to other AT&T subscribers.

I can't imagine another login error aside from the two I've seen. The
only message I've seen for a failed text is when the receiving number
is not an AT&T subscriber (aside from JavaScript checks for things
like the correct number of digits in a number). I wanted to add a
catch-all by regexing the phrase that preceded that message since it
would likely precede any error message ("Your message could not be
delivered because of the following problems..."). Is it the case that
if more than one "check" regex is satisfied, that general error is
issued? That is the behavior I saw when I had two in the "check" list
and both were satisfied.

check: [
{
match: /not a valid AT&T wireless number/,
reason: "Receiver must be an AT&T wireless subscriber."
},
{
match: /Your message could not be delivered because of the following
problems/,
reason: "WebSMS does not recognize this AT&T error."
} ]

Second, given that AT&T provides the error warning, "Your message
could not be delivered because of the following problems.", I wanted
to regex the next sentence out and simply relay it to the user. I
don't see this possible within the "check" list, and trying to set a
"vars" name then use it in the "check" list also results in the
general "Error: Sending Failure!".

vars: [
{
match: /Your message could not be delivered because of the following
problems.<br><br>\s+(.+)<br>/,
name: "ATT_US_ERROR_MSG"
} ],
check: [
{
match: /Your message could not be delivered because of the following
problems.<br><br>\s+.+<br>/,
reason: "%ATT_US_ERROR_MSG%"
} ]

So I have just one error check that catches a non-AT&T receiver number.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "WebSMS" group.
To post to this group, send email to websms-/***@public.gmane.org
To unsubscribe from this group, send email to websms-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/websms?hl=en
-~----------~----~----~----~------~----~------~--~---
claudio
2008-06-19 08:32:09 UTC
Permalink
It is functional for sending a text to myself.  WebSMS has all the  
pieces of the puzzle, then AT&T's service let me down.  While I  
originally thought this would allow me, as an AT&T subscriber, to send  
texts to anyone, I didn't realize the AT&T web page only allows texts  
to other AT&T subscribers.
Apparently phone carriers didn't understand the intrinsic
interoperability behind the web very well.

This is something comparable to the last days of the dinosaurs in
Jurassic, I suppose.
I can't imagine another login error aside from the two I've seen.  The  
only message I've seen for a failed text is when the receiving number  
is not an AT&T subscriber (aside from JavaScript checks for things  
like the correct number of digits in a number).  I wanted to add a  
catch-all by regexing the phrase that preceded that message since it  
would likely precede any error message ("Your message could not be  
delivered because of the following problems...").  Is it the case that  
if more than one "check" regex is satisfied, that general error is  
issued?  That is the behavior I saw when I had two in the "check" list  
and both were satisfied.
check: [
        {
                match: /not a valid AT&T wireless number/,
                reason: "Receiver must be an AT&T wireless subscriber."
        },
        {
                match: /Your message could not be delivered because of the following  
problems/,
                reason: "WebSMS does not recognize this AT&T error."
        } ]
Second, given that AT&T provides the error warning, "Your message  
could not be delivered because of the following problems.", I wanted  
to regex the next sentence out and simply relay it to the user.  I  
don't see this possible within the "check" list, and trying to set a  
"vars" name then use it in the "check" list also results in the  
general "Error: Sending Failure!".
vars: [
        {
                match: /Your message could not be delivered because of the following  
problems.<br><br>\s+(.+)<br>/,
                name: "ATT_US_ERROR_MSG"
        } ],
check: [
        {
                match: /Your message could not be delivered because of the following  
problems.<br><br>\s+.+<br>/,
                reason: "%ATT_US_ERROR_MSG%"
        } ]
So I have just one error check that catches a non-AT&T receiver number.
That won't work since variables are replaced in URLs only, so reason:
"%ATT_US_ERROR_MSG%" won't ever be replaced.

You are not required to provide exhaustive error messages for any
possible situation, you should match the response against the most
common error conditions in order of importance. That is fine enough
IMHO.

I will publish the plugin with WebSMS 2.9.10 very soon.

Best regards,

Claudio
http://www.emeraldion.it

Loading...