Re: [backstage] The best WebAPIs

[Gareth Rodger]

Hi Ian,

Standardised: ATOM would be perfect - What is the lists thoughts on  
GData?


Documented: Upcoming.org have almost no documentation at all but they  
do offer a wiki. Some kind of hosting space would be handy (not for  
us, but for you to host bits from us). I'm thinking of bits such as  
the weather<->Place ID list etc. I say a 'hosting space' as I'd  
imagine you'd have to separate it from official BBC bits.


Formats: First and foremost (for me) is XML. If I was pulling your  
data in Javascript I would opt for JSON. JSON has drowned YAML  
recently but YAML does address some of JSON's shortcomings and I  
believe it'll come back up for air at some point. I've never found it  
to be too much of a task to add alternative parsers.

Does anyone have not-so-favourable experience with YAML?

Dev System: Calls per day is going to be rather quirky in the world  
of widgets - It would be a shame to see something really take off and  
then break in the limelight. If it was too restrictive developers  
could look at caching themselves but that's not ideal.


Authentication: To resurrect up the recent discussion; HTTPS if it's  
private, key based if it's not. Then you run into distribution issues  
as Neil just mentioned. The easiest, fastest solution would be each  
developer having his own gateway :o/


Regards,

Gareth Rodger

W: http://www.garethrodger.com
E: [EMAIL PROTECTED]



On 7 Dec 2006, at 12:48, Ian Forrester wrote:


So it looks like,

RESTful
I guess XML-RPC lost out in everything except blogging and SOAP is  
still too painful for most people.


Standardised
So for example if we embedded everything in the ATOM syntax you  
would like that? Or did you mean something else?


Well Documentated.
Yep, and I really like the idea of a wiki which you guys can also  
edit.


Formats.
My feelings is XML makes a lot of sense. JSON, well I know its  
gotten much love recently but... YAML? does anyone actually use  
this? I thought JSON did away with YAML?

Also who's offering this as a webservice?

Developer system
Yes we will require some kind of authentication system and I guess  
this is where the real debate goes. What kind of interactions would  
you prefer?


How would you feel about us having some developer key system,  
maximum amount of calls a day, authentication?


What have you seen which you like?

I remember Flickr was a pain because you couldn't find your dev key  
easily, while Amazon had a dev token and authentication.  
Technorati's limit of 1000 calls a day is ok but how do people feel  
about the result once you go over the limit? Should error messages  
use http states or return errors in xml?


Thoughts?
Ian Forrester || backstage.bbc.co.uk || x83965



From: [EMAIL PROTECTED] [mailto:owner- 
[EMAIL PROTECTED] On Behalf Of Gareth Rodger

Sent: 06 December 2006 15:44
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] The best WebAPIs

I must agree with the Flickr fans.

In my opinion if it's;
RESTian
Standardised
Well documented
Choice of output formats (JSON, YAML, XML etc.)
An open wiki to supplement the docs
It'll do for me.

Will the BBC require developer keys or authentication?.

Gareth Rodger

W: http://www.garethrodger.com
E: [EMAIL PROTECTED]



On 6 Dec 2006, at 12:58, Neil Roberts wrote:


>>which API's have you used which were a joy to use and why?

I really like the flickr because they offer a simple api for non- 
techies in the form of the badge, which even my dad can use (this  
is a man they type with one finger and that's not one finger on  
each hand but just one finger).


This makes the content really accessible which is important.

And on the other end of the spectrum they offer api's that for the  
true developer that allow you to achieve things like this

http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html

For me this is awesome becuse it not only shows their content up  
in a good light.
It promotes flickr and can inform their service development; all  
things that I think backstage is trying to do for the BBC.


Important things that I have found useful but may not fall into  
the realm of api for some people is:


For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge

For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my opinion  
should be the one that can be used by the most people.
Good documentation and often the best documentation is not found  
on the providers site but on people's blogs, so making the  
documentation an open wiki would help.


neil


On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote:
Right Calm down everyone! :)


Lets put the debate on hold for now (although I was tempted to  
throw in
a line about the GPL3 drafts). I don't know about everyone else,  
but I

Re: RE: [backstage] The best WebAPIs

[Neil Cochrane]

How would you feel about us having some developer key system, *maximum amount 
of calls a day*, authentication?


Great for developers making a pet project, terrible for anyone who
wants to make a redistributable widget.
As widgets are uncompiled, interpreted code; any developer key that
was embedded in one could easily be copied by someone else.
Also they can be used by tens of thousands of people making a few
calls each per day - as a group they can certainly exceeding any calls
per day limitations; and it would be very inconvenient to ask end
users to register for their own developer key.

- Neil

On 12/7/06, Ian Forrester <[EMAIL PROTECTED]> wrote:



So it looks like,


RESTful
I guess XML-RPC lost out in everything except blogging and SOAP is still too
painful for most people.

Standardised
So for example if we embedded everything in the ATOM syntax you would like
that? Or did you mean something else?

Well Documentated.
Yep, and I really like the idea of a wiki which you guys can also edit.

Formats.
My feelings is XML makes a lot of sense. JSON, well I know its gotten much
love recently but... YAML? does anyone actually use this? I thought JSON did
away with YAML?
Also who's offering this as a webservice?

Developer system
Yes we will require some kind of authentication system and I guess this is
where the real debate goes. What kind of interactions would you prefer?

How would you feel about us having some developer key system, maximum amount
of calls a day, authentication?

What have you seen which you like?

I remember Flickr was a pain because you couldn't find your dev key easily,
while Amazon had a dev token and authentication. Technorati's limit of 1000
calls a day is ok but how do people feel about the result once you go over
the limit? Should error messages use http states or return errors in xml?

Thoughts?

Ian Forrester || backstage.bbc.co.uk || x83965



 
 From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gareth Rodger
Sent: 06 December 2006 15:44
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] The best WebAPIs


I must agree with the Flickr fans.


In my opinion if it's;
RESTian
Standardised
Well documented
Choice of output formats (JSON, YAML, XML etc.)
An open wiki to supplement the docs
It'll do for me.


Will the BBC require developer keys or authentication?.



Gareth Rodger


W: http://www.garethrodger.com
E: [EMAIL PROTECTED]





On 6 Dec 2006, at 12:58, Neil Roberts wrote:

>>which API's have you used which were a joy to use and why?

I really like the flickr because they offer a simple api for non-techies in
the form of the badge, which even my dad can use (this is a man they type
with one finger and that's not one finger on each hand but just one finger).

This makes the content really accessible which is important.

And on the other end of the spectrum they offer api's that for the true
developer that allow you to achieve things like this
http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html

For me this is awesome becuse it not only shows their content up in a good
light.
It promotes flickr and can inform their service development; all things that
I think backstage is trying to do for the BBC.

Important things that I have found useful but may not fall into the realm of
api for some people is:

For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge

For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my opinion should be
the one that can be used by the most people.
Good documentation and often the best documentation is not found on the
providers site but on people's blogs, so making the documentation an open
wiki would help.

neil



On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote:
> Right Calm down everyone! :)
>
>
> Lets put the debate on hold for now (although I was tempted to throw in
> a line about the GPL3 drafts). I don't know about everyone else, but I
> personally think this could make a good podcast if I got a few of you in
> a room together.
>
>
> Anyway,
>
> Its almost 2007 and I wanted to ask a question to the list.
>
> One of the things you really want more of, is more BBC API's. Well were
> working on that but I wanted to ask which API's have you used which were
> a joy to use and why?
> Is the documentation, API naming, structuring, amount of data given away
> or something else?
>
> For example, for me Flickr's API is great but I love the security of
> Del.icio.us. The documentation on Flickr is also very easy to follow and
> understand while the ability to run XSL serverside on Amazon's servers
> has been useful. Google Data/Base is very interesting being just ATOM
> based and I can certainly

RE: [backstage] The best WebAPIs

[Ian Forrester]

So it looks like,
 
RESTful
I guess XML-RPC lost out in everything except blogging and SOAP is still too 
painful for most people.
 
Standardised
So for example if we embedded everything in the ATOM syntax you would like 
that? Or did you mean something else?
 
Well Documentated.
Yep, and I really like the idea of a wiki which you guys can also edit.
 
Formats.
My feelings is XML makes a lot of sense. JSON, well I know its gotten much love 
recently but... YAML? does anyone actually use this? I thought JSON did away 
with YAML?
Also who's offering this as a webservice?
 
Developer system
Yes we will require some kind of authentication system and I guess this is 
where the real debate goes. What kind of interactions would you prefer?
 
How would you feel about us having some developer key system, maximum amount of 
calls a day, authentication?
 
What have you seen which you like?
 
I remember Flickr was a pain because you couldn't find your dev key easily, 
while Amazon had a dev token and authentication. Technorati's limit of 1000 
calls a day is ok but how do people feel about the result once you go over the 
limit? Should error messages use http states or return errors in xml?
 
Thoughts?

Ian Forrester || backstage.bbc.co.uk || x83965 

 




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gareth 
Rodger
Sent: 06 December 2006 15:44
To: backstage@lists.bbc.co.uk
    Subject: Re: [backstage] The best WebAPIs


I must agree with the Flickr fans. 

In my opinion if it's;
RESTian
Standardised
Well documented
Choice of output formats (JSON, YAML, XML etc.)
An open wiki to supplement the docs
It'll do for me.

Will the BBC require developer keys or authentication?.


Gareth Rodger

W: http://www.garethrodger.com
E: [EMAIL PROTECTED]



On 6 Dec 2006, at 12:58, Neil Roberts wrote:


>>which API's have you used which were a joy to use and why?

I really like the flickr because they offer a simple api for 
non-techies in the form of the badge, which even my dad can use (this is a man 
they type with one finger and that's not one finger on each hand but just one 
finger). 

This makes the content really accessible which is important. 

And on the other end of the spectrum they offer api's that for 
the true developer that allow you to achieve things like this 
http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html

For me this is awesome becuse it not only shows their content 
up in a good light. 
It promotes flickr and can inform their service development; 
all things that I think backstage is trying to do for the BBC. 

Important things that I have found useful but may not fall into 
the realm of api for some people is: 

For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge 

For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my 
opinion should be the one that can be used by the most people.
Good documentation and often the best documentation is not 
found on the providers site but on people's blogs, so making the documentation 
an open wiki would help. 

neil



On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote: 

Right Calm down everyone! :)


Lets put the debate on hold for now (although I was 
tempted to throw in
a line about the GPL3 drafts). I don't know about 
everyone else, but I
personally think this could make a good podcast if I 
got a few of you in 
a room together.


Anyway,

Its almost 2007 and I wanted to ask a question to the 
list.

One of the things you really want more of, is more BBC 
API's. Well were
working on that but I wanted to ask which API's have 
you used which were 
a joy to use and why?
Is the documentation, API naming, structuring, amount 
of data given away
or something else?

Re: [backstage] The best WebAPIs

[Gareth Rodger]

I must agree with the Flickr fans.

In my opinion if it's;
RESTian
Standardised
Well documented
Choice of output formats (JSON, YAML, XML etc.)
An open wiki to supplement the docs
It'll do for me.

Will the BBC require developer keys or authentication?.

Gareth Rodger

W: http://www.garethrodger.com
E: [EMAIL PROTECTED]



On 6 Dec 2006, at 12:58, Neil Roberts wrote:


>>which API's have you used which were a joy to use and why?

I really like the flickr because they offer a simple api for non- 
techies in the form of the badge, which even my dad can use (this  
is a man they type with one finger and that's not one finger on  
each hand but just one finger).


This makes the content really accessible which is important.

And on the other end of the spectrum they offer api's that for the  
true developer that allow you to achieve things like this

http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html

For me this is awesome becuse it not only shows their content up in  
a good light.
It promotes flickr and can inform their service development; all  
things that I think backstage is trying to do for the BBC.


Important things that I have found useful but may not fall into the  
realm of api for some people is:


For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge

For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my opinion  
should be the one that can be used by the most people.
Good documentation and often the best documentation is not found on  
the providers site but on people's blogs, so making the  
documentation an open wiki would help.


neil


On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote:
Right Calm down everyone! :)


Lets put the debate on hold for now (although I was tempted to  
throw in

a line about the GPL3 drafts). I don't know about everyone else, but I
personally think this could make a good podcast if I got a few of  
you in

a room together.


Anyway,

Its almost 2007 and I wanted to ask a question to the list.

One of the things you really want more of, is more BBC API's. Well  
were
working on that but I wanted to ask which API's have you used which  
were

a joy to use and why?
Is the documentation, API naming, structuring, amount of data given  
away

or something else?

For example, for me Flickr's API is great but I love the security of
Del.icio.us. The documentation on Flickr is also very easy to  
follow and

understand while the ability to run XSL serverside on Amazon's servers
has been useful. Google Data/Base is very interesting being just ATOM
based and I can certainly see more APIs using ATOM as a base result
response in the future.


Don't worry guys we can pick up the Free Software debate later...


Ian Forrester | backstage.bbc.co.uk | cubicgarden.com


Laurence Samuels wrote:

> You explained these a long time ago, and you kept on repeating what
> did not amount to new knowledge. I hope you wont reply to this  
email.

> If you do, I wont reply to the list, I might reply to you privately.
>
> L

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe,  
please visit http://backstage.bbc.co.uk/archives/2005/01/ 
mailing_list.html.  Unofficial list archive: http://www.mail- 
archive.com/backstage@lists.bbc.co.uk/




--
"I like work: it fascinates me. I can sit and look at it for hours."

Re: [backstage] The best WebAPIs

[Simon Cobb]

it's not an API, but I like the javascript library 'mochikit':
http://mochikit.com/  

I like that it is lightweight, practical, tidy (because it's modelled on
a tidy language - Python) and feels so clean to use. 

And the docs are exemplary in my view.

Basically, it doesn't waste my time. That's what I would want from a BBC
API.
 
S.
 
bbc.co.uk/cbbc/
bbc.co.uk/cbeebies/

 
 

Re: [backstage] The best WebAPIs

[Neil Roberts]

which API's have you used which were a joy to use and why?


I really like the flickr because they offer a simple api for non-techies in
the form of the badge, which even my dad can use (this is a man they type
with one finger and that's not one finger on each hand but just one finger).

This makes the content really accessible which is important.

And on the other end of the spectrum they offer api's that for the true
developer that allow you to achieve things like this
http://www.webmonkey.com/webmonkey/06/08/index4a_page2.html

For me this is awesome becuse it not only shows their content up in a good
light.
It promotes flickr and can inform their service development; all things that
I think backstage is trying to do for the BBC.

Important things that I have found useful but may not fall into the realm of
api for some people is:

For the novice:
Restful/guessable/hackable URLs
A range of simple standard RSS feeds
Examples and easy to use interfaces eg: flickr badge

For the not so novice:
Parameterised RSS feeds
HTTP implemention is always good but the technology in my opinion should be
the one that can be used by the most people.
Good documentation and often the best documentation is not found on the
providers site but on people's blogs, so making the documentation an open
wiki would help.

neil


On 12/6/06, Mr I Forrester <[EMAIL PROTECTED]> wrote:


Right Calm down everyone! :)


Lets put the debate on hold for now (although I was tempted to throw in
a line about the GPL3 drafts). I don't know about everyone else, but I
personally think this could make a good podcast if I got a few of you in
a room together.


Anyway,

Its almost 2007 and I wanted to ask a question to the list.

One of the things you really want more of, is more BBC API's. Well were
working on that but I wanted to ask which API's have you used which were
a joy to use and why?
Is the documentation, API naming, structuring, amount of data given away
or something else?

For example, for me Flickr's API is great but I love the security of
Del.icio.us. The documentation on Flickr is also very easy to follow and
understand while the ability to run XSL serverside on Amazon's servers
has been useful. Google Data/Base is very interesting being just ATOM
based and I can certainly see more APIs using ATOM as a base result
response in the future.


Don't worry guys we can pick up the Free Software debate later...


Ian Forrester | backstage.bbc.co.uk | cubicgarden.com


Laurence Samuels wrote:

> You explained these a long time ago, and you kept on repeating what
> did not amount to new knowledge. I hope you wont reply to this email.
> If you do, I wont reply to the list, I might reply to you privately.
>
> L

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  Unofficial
list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/





--
"I like work: it fascinates me. I can sit and look at it for hours."

RE: [backstage] The best WebAPIs

[Jason Cartwright]

Sure, I kinda agree. I did say "I appreciate the use of the *standard*
HTTP Authentication".

I'm torn - I agree that it is already a built-in and proven tech.
However other APIs just lets me pass the auth gubbins like any other
argument... which is just so damned easy-peasy.

J

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Armitage
Sent: 06 December 2006 11:13
To: backstage@lists.bbc.co.uk
Subject: RE: [backstage] The best WebAPIs

Quoting Jason Cartwright <[EMAIL PROTECTED]>:

>> For example, for me Flickr's API is great but I love the security of
> Del.icio.us.
>
> Flickr's API is the best I've seen because...

[snip]

> I didn't like del.cio.us' security. Whilst I appreciate the use of the

> standard HTTP Authentication it presented a barrier between me and the

> data. I'd rather pass my authentication info as another argument (a la
> Flickr) rather than messing with HTTP authentication [1]. Del.cio.us 
> often runs slowly, which can't be helped by all API requests go over 
> HTTPS. I'd argue HTTPS isn't really needed anyhow - its not like its 
> my credit card details we're talking about, just my already public 
> bookmarks!

I'd argue that del.icio.us is doing things right here. You say "messing
with HTTP auth"... but really, that's the right way of doing things.
HTTP already has an authentication method built into it...  
implementing one's own is reinventing the wheel, surely?

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe,
please visit
http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive:
http://www.mail-archive.com/backstage@lists.bbc.co.uk/

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

RE: [backstage] The best WebAPIs

[Tom Armitage]

Quoting Jason Cartwright <[EMAIL PROTECTED]>:


For example, for me Flickr's API is great but I love the security of

Del.icio.us.

Flickr's API is the best I've seen because...


[snip]


I didn't like del.cio.us' security. Whilst I appreciate the use of the
standard HTTP Authentication it presented a barrier between me and the
data. I'd rather pass my authentication info as another argument (a la
Flickr) rather than messing with HTTP authentication [1]. Del.cio.us
often runs slowly, which can't be helped by all API requests go over
HTTPS. I'd argue HTTPS isn't really needed anyhow - its not like its my
credit card details we're talking about, just my already public
bookmarks!


I'd argue that del.icio.us is doing things right here. You say  
"messing with HTTP auth"... but really, that's the right way of doing  
things. HTTP already has an authentication method built into it...  
implementing one's own is reinventing the wheel, surely?


-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

RE: [backstage] The best WebAPIs

[Jason Cartwright]

> For example, for me Flickr's API is great but I love the security of
Del.icio.us.

Flickr's API is the best I've seen because...

* Beautifully structured documentation
* Fast
* Loads of methods
* Methods added regularly
* Well supported by the community with kits and examples in *many*
languages
* Highly persuasive data (photos of me and my friends)

I guess half of this is caused by the fact that the AJAX goodies on
flickr.com itself acquire data from the API.

I didn't like del.cio.us' security. Whilst I appreciate the use of the
standard HTTP Authentication it presented a barrier between me and the
data. I'd rather pass my authentication info as another argument (a la
Flickr) rather than messing with HTTP authentication [1]. Del.cio.us
often runs slowly, which can't be helped by all API requests go over
HTTPS. I'd argue HTTPS isn't really needed anyhow - its not like its my
credit card details we're talking about, just my already public
bookmarks!

J

[1] When I consumed the del.cio.us API I was using ASP.net, which
required the use of System.Net.NetworkCredential and
System.Net.WebRequest to pass the HTTP Authentication details. Not a big
deal it turns out - but more hassle and different to all the other APIs
I had consumed in the same app. Just annoying.


Jason Cartwright
Client Side Developer - CBBC Interactive
[EMAIL PROTECTED] 
 
Desk: (0208 22) 59487
Mobile: 07976500729
 
"Recreate the world in your own image and make it better for your having
been here" - Ray Bradbury

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] The best WebAPIs

[Richard Lockwood]

Lets put the debate on hold for now (although I was tempted to throw in
a line about the GPL3 drafts). I don't know about everyone else, but I
personally think this could make a good podcast if I got a few of you in
a room together.


True.  Does the BBC still have Harry Carpenter under contract?  He
could provide the commentary.

Cheers,

Rich.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

[backstage] The best WebAPIs

[Mr I Forrester]

Right Calm down everyone! :)


Lets put the debate on hold for now (although I was tempted to throw in 
a line about the GPL3 drafts). I don't know about everyone else, but I 
personally think this could make a good podcast if I got a few of you in 
a room together.



Anyway,

Its almost 2007 and I wanted to ask a question to the list.

One of the things you really want more of, is more BBC API's. Well were 
working on that but I wanted to ask which API's have you used which were 
a joy to use and why?
Is the documentation, API naming, structuring, amount of data given away 
or something else?


For example, for me Flickr's API is great but I love the security of 
Del.icio.us. The documentation on Flickr is also very easy to follow and 
understand while the ability to run XSL serverside on Amazon's servers 
has been useful. Google Data/Base is very interesting being just ATOM 
based and I can certainly see more APIs using ATOM as a base result 
response in the future.



Don't worry guys we can pick up the Free Software debate later...


Ian Forrester | backstage.bbc.co.uk | cubicgarden.com


Laurence Samuels wrote:

You explained these a long time ago, and you kept on repeating what 
did not amount to new knowledge. I hope you wont reply to this email. 
If you do, I wont reply to the list, I might reply to you privately.


L


-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/