Also keep in mind that many web browsers, particularly those in mobile phones might not work properly with JavaScript cruft. Imagine you’re somewhere deep in the stacks and you want to look something up – why not do it right then and there instead of going to find a computer?

Cookies are better but still unwieldy. I agree with Owen that if at all possible tokens in nice stable (RESTful) URLs are the best.

What I meant was that before we can answer the question of how to best ‘protect’ the feeds, we need to understand how they might be used.

Since my immediate desire is to reuse the feed in some way, then it would be much easier if you followed your suggestion of a unique id in the URL – as then I can make the decision straight away of how I reuse – I can embed in various environments without sharing the details (e.g. in my own blog), or if I want I can tell other people the location.

So – there’s my vote!

However, I can understand others might only want to use the marked list within the COPAC environment, and don’t care about reuse, but do care about security – and they are going to have a different answer.

In terms of the beta, it would be great (IMO) to do it as a unique token in the URL, because then you will see experiments in reuse as well – which is impossible while it is protected with Shib.

What we are trying to do is make the data available in ways that are easy to work with so that people can do things with it that we haven’t envisaged. The potential is also there to add data from services other than Copac.

The ability to make your feeds public will come… (sooner rather than later.)

Ashley.

This seems to work fine – I can access the feed in my browser. However, if I try to add it to Google Reader it sees it as empty (of course)

However, I think we need to get down to some use cases on this. Why would I want to access a feed of my own searches/refereces in a feed reader? This seems an unlikely application as I don’t need to be updated on this.

The first use that comes to mind is the ability to embed the list into other web resources – but for this to happen I’d need to be able to make the feed publicly available – so the idea of a simple dedicated URL appeals in this instance.

What other use cases are there?