It doesn't take the information from the portal, although ultimately the portal and the new web service client use the same source for the information. Current stats are live, from the routers and the historical stats are from a database.

The app is still in internal testing although I can provide some quick features which should make it into the release.

* System tray app with "pop-up bubble" showing the current month's details of your default account.

* Grid display of historical or current data for any Zen broadband account that your portal username has permission over which means that for some users who have permission over multiple accounts, they can see the stats for all these accounts in one place. The stats appear in a grid which enables copying and pasting to whichever app you like.

* Can choose only current month or figures for any previous month(s) using a date range selector.

Unfortunately this release is for Windows (with the .NET framework 2.0) only at this time.

Expect the release within the next few weeks. I realise we have said this before however some issues had to be addressed so the release had to be postponed.

Will you be releasing the protocol specification at the same time so third party monitoring tool authors can use the back end servers instead of screen scraping the portal?

I'm hoping for something nice and simple like XML, and that this isn't just going to be an browser control running in a window with everything happening on the server....

Cheers,

Tim.

No, at this time the only thing to be released will be the client app itself. This decision may well be reviewed at a later date. We realise this differs from our previous stated intention and apologise for this.

There is no screen scraping involved. The client app talks to a web service on one of external servers.

Thanks for the reply. It's a bit of a shame, but hopefully the application will be sufficient for most people's needs; I look forward to seeing it!

Cheersm

Tim.

So, with one stroke you dismiss all those who use Linux and Macs, those who were ready to write web front ends, those who do not have .Net installed, those on .Net 1.0 and 1.1...

NOT GOOD ENOUGH!

If it's a web service then it's not OS specific, it's just that the initial client will be .NET based.

I'll follow this up and see what needs to be done to make a Perl based client to grab the info as well.

This isn't a final "We will never release the source or the specification" decision. It is only a statement that at this time we will not be releasing the source code or the specification for the web service. This is not going to be a supported service, more of an extra for those who require it.

The WSDL file for the web service will be available for those that want to see the structure of the SOAP requests and responses.

Like I say, this decision may change. The initial client app release will be BETA only and suggestions or bugs are welcome. As jander says, we will try and investigate the possibility of releasing a more simple PERL client complete with source code.

I don't think "NOT GOOD ENOUGH" is really warranted as the tool is a tiny little extra that you're not contracted to have as part of your service to begin with.

It is the interface to the web service that I am interested in.

Is it good enough that they pander to the windoze crowd only when one of their selling points is that they support Macs?
Is it good enough good enough that they promised a web service that could be used by all and then don't deliver?

Jump onto the fanboy wagon if you want, but allow others to complain if promises are not fulfilled.