We have been working on the idea of an API for true main A&A control systems (known as "clueless"). The problem is that it is potentially quite a complex project and so we struggle to start it.
However, following on from my comment on banks, it is a fair comment to ask what A&A can do.
So, one simple idea is we do the same - a simple email every day or week or whatever with an XML of various data. This could include the usage stats, and perhaps the data we get on talk talk lines for attenuation and margins. As XML it is relatively easy to add more data later.
So, we'll look in to doing that. It would be interesting to hear from customers what data they would like.
This will save some people screen scraping clueless's web interface, and means we can send the data as a background batch job and reduce load.
Obviously encryption may be sensible too. We need to sort a way to log customer PGP keys sensibly, and allow them to be updated, etc.
Subscribe to:
Post Comments (Atom)
Deliveries from China
I have PCBs made in China (well Hong Kong). This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Per IP, per charge time band up & down usage would be a goldmine of information for me.
ReplyDeleteRegularly emailing scraped-up log information doesn't really seem anything like an 'API', and it's not really the kind of thing I've wanted when asking about a Clueless API in the past.
ReplyDeleteWhy not just provide the same XML via an HTTPS GET request? That would remove all need for per-customer configuration (PGP keys, email addresses, schedule, etc), the code to generate the XML is the same effort anyway, and you already have the HTTPS server and some method of authenticating GET requests against a customer.
That is the point - this is not a full API, as that is a lot of work to even get started. This is an interim measure that is relatively easy and meets the requirements for lots of people.
DeleteMaybe I am missing the point in the same way as Will (I have no requirement of an API btw) but I think Will is saying rather than a "full" API, you implement a "single command" API (in a manner of speaking).i.e. no frills, just one request - to get everything you are thinking of emailing anyway.
DeleteAs Will says, you are generating the XML anyway (or if it is pre-generated somewhere then it can just be retrieved at time of request), and you have the HTTPS server and authentication with clueless.
On the customer side, it can then just be retrieved easily by a script etc, and then parsed afterwards, without fiddling around with email, PGP etc.
Or are we still missing the point? :-)
I'm rather hoping for some much simpler calls that return the current up/down sync rates (per line), so that there's no need to scrape the log page for that info :¬)
DeleteI'm with Dan here - and we're clearly talking across RevK in some way - we're saying A. "don't bother with some 1990s-style email thingy", and B. "if 'API' is interpreted within A&A to mean 'something very complicated', then don't bother with that either". Instead just provide the XML information you're proposing to provide anyway, but via HTTP rather than SMTP.
DeleteI'm aware that Clueless is probably not some nice modern platform where adding support for a new GET request is about two lines of code, but really we're asking for something which sounds as though it should be considerably *less* complex than the emailed XML approach. There's no particular obvious reason (as an outsider) why it needs to be part of some mega project which involves rewriting all the front end at the same time.
This comment has been removed by the author.
DeleteThis comment has been removed by the author.
DeleteI'm with Will and Dan on this - email is not the way to go. I can think of at least 6 ways to grab a file from a webserver across multiple platforms, but I cannot think of a single 'out of the box' script that allows me to
Delete1) Log into a mailserver
2) Open a mailbox
3) Look for an email from a specific sender
4) Download an attachment from that email
5) Decrypt it
6) Then push it somewhere for processing.
Its overly complex and seems like reinventing the wheel when services like cURL exist. Generate the XML as you intend, but then push the file to the users account on clueless or some other server protected with a mutually agreed authentication token. KISS
I know there is a risk that everyone will try and log in at midnight to fetch the file, but Id imagine the XML is relatively lightweight in most cases.
This comment has been removed by the author.
DeleteGet a better MDA, perhaps procmail and process when things arrive?
DeleteProcessing an email on receipt is a doodle, surely. You make a specific address for it, and process on receipt. As David says.
DeleteWhile it won't help for existing bits and pieces, as a suggestion for any new services / features you add, what I always try to do is develop the API *first*, and then make my own frontends use that API. This way it ensures the API can do everything the frontend can do, rather than it being bolted on afterwards and potentially missing certain bits and pieces.
ReplyDeleteIt can also make testing easier, as you haven't got to put together the full UI to manage things, just a few wrapper scripts around the API...
I completely agree - and indeed, moving to that, making a new API and then scrapping the existing web interface to make it a front end using the common API, is the "Grand plan" on which we keep getting stalled. It is a nice way of doing it and proves the API is fit for purpose in the process.
DeleteA plain text based version of http://a.soulless.thn.aa.net.uk/info.cgi would be very handy!
ReplyDelete1. Usage data for internet lines
ReplyDelete2. Sync up and down for internet lines
3. CDR via API would be very very useful (ideally submitting a request for all data on an account for a date range)
In the longer term changing of destination numbers for DDI's
One small and hopefully easy step in the right direction would be for Clueless to accept HTTP authentication rather than relying on sessions and cookies.
ReplyDeleteXML might be nice, but a plain text dump would be better than nothing (then easy to retrofit XML to later): most of us just want to grab simple numbers or lines of text. Actually, even if you did have XML, the plaintext would probably be more useful for most of us.
"curl -u fred:CrunchySocks https://clueless.aa.net.uk/dump.cgi | grep line-sync: | cut -d: -f2" is what I'm actually after.
Why stick with PGP? I use certificates and would prefer S/MIME.
ReplyDelete