* Home * SlinkP Linux Pages * soundapp_site_roughs
Last updated Jun 30, 2007 1:53 pm GMT-5

Paul's Linux Soundapp Site progress notes

what it's all about

I'm trying to put together a dynamic website to supercede Dave Phillips' venerable linux audio software listing at http://sound.condorow.net. I plan to use my favorite web development platform, Zope, and most likely will use CMF, possibly Plone with a simplified UI, and possibly Archetypes for defining the content types.

Status:

Not much to report.

Rough mock-up of a typical page. Not meant to be pretty, just give an idea of the information presented on a page.

Background discussions: There has been some discussion of this project on the linux-audio-user mailing list. See www.linuxdj.com/audio/lad/user.php3 for list info. To get up to speed, here's the most relevant discussions so far: A couple of points on the state of linux audio apps (2002) ... and New Linux soundapp site progress (2002)... and sound & midi applications page (2004)... and Features / Requirements for new soundapps page (2004). Note that clicking "next message in thread" may result in skipping some messages.


Requirements (in progress)

What the site should be & provide, and what it should NOT be and NOT provide. For commentary, see the linux-audio-user list.
ESSENTIAL FEATURES
------------------

* Accessibility.  The site should have minimal browser requirements in
order to function (looking nice is a different story). e.g. it should
be useable in a text-only, no-javascript browser. No frames either,
"they're not very good for blind people".

* Software entries.  Each of these describes a piece of software.
  Information we can store for an app:

  -Principal Author(s)
  -Home Page
  -Download Page
  -Documentation link(s)
  -Mailing Lists/Forums (URLs for project mailing list, project forum, linux-audio-user, ...)
  -Latest version #
  -Latest release date
  -Development Status (new, alpha, beta, stable; also active, orphaned)
  -License (GPL, LGPL, BSD, ...)
  -I/O Compatibility (JACK, OSS, ALSA, Portaudio, ALSA sequencer,...)
  -UI(s)  (Qt, Gtk, WxWindows, Tk, curses, command line, ...)
  -Software type (standalone app, plugin, development library,...)
  -Categories (see below)
  -Description (short)
  -Screenshots?
  -Example audio files?

  Many of the above will be optional. You shouldn't need to know
  everything about an app to post an entry.

* DublinCore metadata for each app or doc entry.

* Info entries.  Each of these describes a piece of
  information or documentation (examples listed below). 
  Information we can store for an info entry:

  -Principal Author(s)
  -Latest update date
  -Link
  -Development Status (new, alpha, beta, stable; also active, orphaned)
  -License
  -Type (Book, Print Magazine Article, web article, Interview Site,
    Wiki, HOWTO, manual, "cookbook", tutorial, FAQ...) 
  -Categories
  -Description (short)

* Categorization. 
  Software categories will be used as the primary 
  means of navigation. 

  A single software entry can appear in multiple categories.

  Categories will likely be a superset of relevant Trove categories.

  Specific categories are still being discussed.
  Examples might include: Soundfile Editors, Players, 
  MIDI Sequencers, Software Synthesizers, ...

  
* Basic search that does a simple case-insensitive text search for a 
  string.

* Advanced search with lots of nice criteria.
  This will evolve as time goes on.

* Registration / login, in case you want your postings to have your
  name on them. It's been pointed out to me that we should not unduly
  restrict anonymous users, unless abuse makes it really necessary.
  Notably, anonymous users need to be able to add & update app
  listings. 

  Anonymous users will probably *not* be allowed to permanently delete
  anything.  Revisions will be tracked for a reasonable length of time
  so we can recover from mistakes & abuse.

* Reviews. Each software listing page will allow users to post
descriptive reviews of the software.
The review form should attempt to gather information such as:
 - what version(s) of the software the reviewer tested
 - how much time the reviewer spent on the software
 - similar software the reviewer has used
 - which distribution
 - which kernel
 - whether the software was compiled from source, installed
   from a distribution package,...
 - ease of installation
 - summary of "plusses"
 - summary of "minuses"
 - the main body of the review: a large free-form text entry widget.


* Comments. A forum / blog-like threaded comment system.  You can
comment on reviews, app descriptions, Musings, other comments...

* RSS feed of updates & new listings.

* RDF export of the whole dang thing?

RANDOM FEATURE IDEAS
--------------------
these are not really essential but might be nice to have.

* email subscription to entries - optionally get notified 
by email when some page is changed.

* categorization, properties, and schema available as RDF.

* automatically track updates from Freshmeat by using their RDF data.

* Musings.  A regular blog-like column in which Dave Phillips can say whatever
he wants.  This feature of the old site is too good to lose :-)
Assuming, of course, that Dave wants to keep writing these.  I'm a bit
torn on this - on the one hand I'm inclined to make it open to all (or
at least all registered) users to post such columns, and I don't want
to be seen as playing favorites; OTOH I'm not sure I want to let the
focus slip and become a wide-open discussion forum or turn into a
collection of personal blogs.  Also, maybe there is a more appropriate
place for Dave to post his regular musings - like his own website :-)
If so I will be happy to provide a links section for things like this.

* Personalization.  When logged in, have your own home page that shows
  e.g. only the categories you are interested in by default, and maybe
  quick links to your favorite entries, that sort of thing.


REJECTED FEATURES
------------------

* App ratings. There was some discussion of this and we generally
agreed that numeric ratings provide very little useful information and
go out of date too quickly.

* Documentation & how-tos.  Other sites are doing this, notably the
djcj quicktoots site, also LinuxMusician, probably others;
don't duplicate the effort.

* News articles. MStation is doing this, LinuxMusician is doing this,
maybe other sites too; I don't want to duplicate the effort.
Instead we should just link to those sites where appropriate.
And we should all provide rss feeds for each other :-)


SECURITY FEATURES
-----------------

The site should be as open as possible but I do not intend to 
let it be abused by waRez d00dz and the like. Some minimal
precautions seem worthwhile:
 
* Text entry widgets will have a (reasonable) limit on the 
number of characters allowed. 

* Binary uploads may either be disallowed (which would mean
screenshots and sound samples must be linked elsewhere),
or restricted in size. Comments on this?
I don't want the site to require heavy-duty hosting.

* Revisions will be kept until cleaned out by site admin(s).
This is easy, given that the planned platform (zope) provides
this feature out-of-the-box.  This would prevent rival
soundfile editor authors from deleting each other's pages
permanently ;-)

* There may be an admin mailing list which receives daily
logs of all additions, changes, and deletions.

* We may limit frequency of anonymous postings by IP, 
similar to the way that slashdot does, to mitigate the possibility of bots
accidentally or maliciously filling up our database.


PERFORMANCE REQUIREMENTS
-------------------------

The site should be thoroughly load-tested and should hold up to being
slashdotted :-) Steve H. gave a data point: 1 M requests / hour during
a slashdotting.  (277 requests / sec avg.)


"Normal" usage should be much lower, DLP reports approx. 20k
hits/month on each of the current mirrors (avg 0.5 req/sec).

The primary performance strategy will be aggressive caching.
Serving information that is some (10?) minutes out of date should be perfectly
acceptable.  Squid or Apache would do the trick.

Title ideas

The site needs a name. Some suggestions from the lists thus far:
Big Linux Audio Repository -- BLARe
Audio & Music Apps for Linux (AMAL)
Linux Audio Festival (LAF)
Linux Audio Free Totally Encompassing Resources (LAFTER)
Linux Audio Land  (LAL)
Linux Audio & Music App List (LAMAL)
Linux Audio & Music Software Database
Linux Sound Pavilion
Linux Sound Roadmap
Linux Sounds Zoo
Linux Waves
Raiders of the Lost Softs
Software for Linux Audio & Music (SLAM)
Sound & MIDI Software For Linux*
Cyborg Musicians Club
The List
The Shaking Warehouse
Freshsounds
Noisenix
Tuxsound
Tuxaudio

* an oldie but goodie :-)

     Send me some mail slinkP home page Powered by Zope