In addition sto @sotawatch could we have an @ SOTAwatch$REGION
e.g. @ SOTAwatchGW which would only tweet the GW summits.
An interesting idea. The snag is that I would need to maintain over 50 additional Twitter accounts, and ensure that I have a procedure to obtain another whenever a new association appears. Not only is this a fair amount of work, but it may risk falling foul of Twitter’s multiple account AUP.
I’ve had a similar request for feeds tailored for the spots that stand a reasonable chance of being received in specific areas of the world. The particular request was a feed tailored for North America. This is perhaps more manageable in terms of the number of accounts needed, but it means building in a model of what should be included, and I fear this could lead to endless argument.
The real problem is that Twitter isn’t the ideal tool for the job, since it doesn’t allow the individual to be selective about what is received. Its main advantage for our purposes is that it is a way of getting SMS alerts delivered free of charge. A service that did the SMS delivery itself could do a better job (users could register a filter pattern, for example) but somebody would have to pay for SMS delivery.
The biggest problem is not having to have multiple accounts (which is a problem) but building in the need to have to perpetually update the code as new associations appear. It’s a guaranteed point of weakness that you wouldn’t want do if it could be avoided.
The easier way is to filter on the phone. The SMS API is visible on Symbian (in its death throes), Android and JobsPhone so it wouldn’t be a huge job to write one. You can then get your local app to apply the filter and play the appropriate alert tone depending on the SMS. i.e. non-SOTA get the normal alert, SOTA-filtered don’t get alerted and the wanted ones cause you phone to sound and jump about like a demented Dervish dancer.
Twitter is cool as you can get it to send SMS for free and it has serious throughput capabilities. I’ve looked into what could be sent out my SMSbot but the problems are throughput and cost. I can send about 15 SMS a minute and if all 150 users wanted to be alerted when spots came in it would take me 10mins to do so. And if more spots came in… you can see the problem with handling it locally. Then there is the cost. I need people to pay up front as Europe uses the sending party pays fully model and have to have some accounting code that stops sending when they run out of credit. It’s messy.
My US SMSbot is more extensible in this way as they have a receiving party pays model and the SMS transport is Google. Google is not short of bandwidth and I don’t have to worry about racking up a bill sending messages! I’ve thought about offering the ability to allow users to request the system to forward spots with the control being over the SMS channel but not had any time to seriously flesh out the idea.
[For those who wonder for the reason for using SMS over a pure mobile internet feed is the fact that SMS is more reliable transport medium on summits that mobile internet.]
Given limitless budget it’s easy. Anyone got a big bag of cash they don’t want?
building in the need to have to perpetually update the
code as new associations appear.
I’d avoid that by naming the accounts systematically and keeping the credentials in a data file (they are already, in a fairly crude way). But I’m still not keen on doing it.
