This is a placeholder for a more refined use case. It will be edited soon. In the meantime, here is an email I wrote to the LS and Campsite developers outlining the general functionalities - doug
========================
Before I put together a classical use case in the LS sense of the term, here are a few notes on what I'd like to see.
In a perfect world, the portal aspect of the site would work essentially the same as the NPR's PRX (http://www.prx.org), which serves two main classes of users: The general public, which has the ability to search and browse the available material for streaming and/or download, and member stations, who can search and browse a larger number of programs for use on their individual stations.
PRX has a portal-like front page, as well as pages for each of the shows it has inside. On our front page, I would like to see the ability to post text news, similar to what MDLF client FNR does on its home page (http://www.fnr.ru), or what Ammannet (www.ammannet.net) or Ideeleradio already do with their Campsites.
Back to PRX. As most of the shows stored on PRX have multiple episodes, there is a page for each of the shows, and from there users can navigate to individual episodes. As an example, here's a page for a show called Western Folklife Center Media:
http://www.prx.org/group/westernfolklife/pieces
On this page, users have the ability to either read about the show (in Campsite terminology, I guess this would be the article), and then to browse for individual files (they call them "pieces").
http://www.prx.org/pieces/8488
Users can then either download the files or stream them, depending on whether they're registered users. In this case, registration means that you are an employee of a radio station and are seeking to download the files for broadcast on your station; there is an accounting mechanism that keeps track of what you've downloaded, and how much you owe for the downloads you've made. In our case, that isn't necessary at this phase, but will probably become more important over time.
In addition to browsing via the front page, there are also search mechanisms. The PRX search options are pretty large, and to be honest I'd rather see something like we have in the LS search/browse pages, if that's feasible for larger numbers of users. FNR's RAEN exchange site (http://www.raen.net) also has a number of useful functions, including the ability to browse by duration and by rating.
OK. I hope this moves us along a bit.
doug
Paul Baranowski <[email protected]> 01/18/2006 08:36 PM
To: [email protected] cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: Integrating LiveSupport and Campsite 2.4
Can you send us some use case scenarios for this feature?
Sava and I see two:
1) Go to google-like page, type in search string, get list of files (with descriptions).
2) Write article and attach a livesupport audio file to it.
- Paul
[email protected] wrote: > > Hi guys, > > One of the tasks we have before us with our radio networking project in > Sierra Leone is the creation of a portal for browsing and searching > program content submitted by member radio stations on a virtual radio > network. A question we have in front of us is whether to use Campsite > for the portal backend, or to put something together on a custom basis > that would be part of the LiveSupport HTML UI. > > If we decide to go for integration between the two projects, there'll > have to be a meeting of mimes between the two projects. And we know a > mime is a terrible thing to waste ;-) > > A little background: > > When a file is added to the LiveSupport storage server, it is stored on > the filesystem with a machine-readable name: > > /opt/livesupport/var/LiveSupport/storageServer/var/stor/0d4/0d44bb57d7cecb29 > > > and its metadata is in an accompanying file: > > /opt/livesupport/var/LiveSupport/storageServer/var/stor/0d4/0d44bb57d7cecb29.xml > > > One thing that occurred to me was that the Campsite article fields for > such an instance could be made to match LiveSupport's metadata fields on > a 1-to-1 basis, so that, from the Campsite API's perspective, it's > getting a new article, one with a number of the metadata fields filled out. > > The important fields, namely, "Name", "Creator" and "Description" would > map to their Campsite equivalents, with additional fields being added on > as is currently done. > > The question comes with where the actual sound file would be stored. > Ideally, the storage would still happen on the LiveSupport > StorageServer?, but it would be really nice if we could set it up so that > there'd be a symlink attached to the article that would point to the > file in the StorageServer?. > > As I see it, from a user perspective, the portal itself would only > provide an interface to files on the network's StorageServer?. All file > uploading and metadata editing would happen through the LiveSupport app. > It would be nice to have the opportunity to write to the metadata from > Campsite, especially so that an extended article text could accompany > the file; but that may not be possible given the circumstances. > > The question is whether you think this approach is feasible. > > For Paul and Mugur, Sebastian has made a repository for his LiveSupport > Debian packages, and they install nicely on Ubuntu. Just add this line > to your /etc/apt/sources.list file: > > deb http://yellowsunshine.de/1.0.2-4 sarge main > > I'm enclosing a sample LiveSupport metadata file here for your perusal > as well. > > > > Looking forward to getting some dialogue going on this, > > doug
