[cap-talk] Music organizer example (was: Capabilities and Freedom vs. Safety)

Sam Mason sam at samason.me.uk
Sun Jul 22 21:03:22 EDT 2007


On Sun, Jul 22, 2007 at 10:51:42PM +0100, David Hopwood wrote:
> That is straightforward to implement without requiring that a
> single program have all the permissions involved.
> 
> Player instance:
>  - sound output
>  - read access to a data pipe
>  - access to its own window if needed
> 
> Organizer:
>  - read all metadata of files in the music database
>  - send a file to the player's data pipe
>  - access to its own window
> 
> Downloader instance:
>  - communicate with some set of Internet sites
>  - send a file to the player's data pipe
>  - add a file to the music database
>  - access to its own window

I'm wondering why the player and organiser have been separated into two
separate processes?  I'm not quite sure what's going to be gained:

   File formats, the organiser will probably have to know about every
  format the player does in order to handle the metadata correctly.

   Sound output, if the organiser is giving the player the file to play
  then the organiser has a pretty much direct path to the output device.

   User-interface, doesn't seem to be an issue either way.  Tight
  integration between player and organiser may be nice, otherwise it
  might be nice to know that you're at least going to get to the end of
  this track if the organiser dies.

It's the sound output that bugs me, if the organiser is giving the
player the file then what's to stop it giving the player whatever data
it likes.  The organiser will also know when the user hits pause or
another control button like next track, as the requests to stream the
data will stop or the next file on the playlist will be requested.

In slightly more definite terms; I can see that separating the player
and organiser would be beneficial for reasons of modularity and
reuseability, but don't see this separation reducing the organiser's
authority in any meaningful way.


  Sam


More information about the cap-talk mailing list