as a general point, I think it's not worthwhile to standardise
specifically on SMS. it's not _that_ universal, and it's also being
phased out by MMS, which is just good old MIME documents (transported by
HTTP for the last hops, but SMTP for routing).
I don't yet know enough about MMS sadly to make comment :o(
a limit on message length is a good option to add, but it shouldn't be
based on SMS chunk size.
Why are they setting a limit though? Partly due to how much text they want to
scroll through, but more todo with how much it's going to cost them. Isn't it
the standardised SMS chunk size the root of the cost for SMS just now? If we
make the limit based on message length, then we require that our users have
some knowledge of how long a message they can have for one SMS chunk and
therefore keep their costs down.
Each phone number must begin with a + and
include the country code to ensure that the script will work
regardless of location of server/script.
is it important to trap this at compile-time?
I think it's similair to the desire to catch invalid variable names at compile
time. So yes, I think so.
if header :matches "*" "To" {
set "Recipient" "${1}"
}
if header :matches "*" "From" {
set "Sender" "${1}"
}
if header :matches "*" "Subject" {
set "Subject" "${1}"
}
set "Message" "[To: {$Recipient} From: {$Sender}] {$Subject}"
(you'll have to switch the arguments, it's header COMPARATOR header-name
pattern)
Ug I never did find the order intuative...
(I note that my intuative use of * won't work cos * in matches
according to variables is non-greedy, yet * with regex is greedy, but
I thought I'd do that deliberately to make you think...)
greediness doesn't come into play here, as :matches "*" == :regex
"^(.*)$"
I'm happy that that is the case but is that obvious to everyone? It wasn't
obvious to me, and I don't recall reading that it was ever specified. I think
we have another thread on this topic though...
$HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
$HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
$HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
this is just a different syntax for:
${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
Yes, I would have suggested that instead, but I suppose I wondered if such a
mechanism would mean we'd have to predefine all header names we'd ever use. I
thought perhaps the use of the associative array made it clearer that the
header might not actually exist in the email, and therefore cope with all
future header names.
(the variables draft doesn't allow the last component of the variable
name to be a number. I think that is an aspect we can change if we want
to, but it must be done now.)
I think it preferable to allow array syntax instead of variables starting with
numbers.
anyhow, doing it via a namespace makes it more natural to present the
information in a parsed manner. e.g., you could have an
header.date.year == "2005" in addition.
Indeed, that might work neatly!
If we were to do this then where would such a mechanism be specified? 3028bis,
variables, new draft? I'd love it to be available in the variables spec...
Nigel