The Digital Age: Difference between revisions

From Bitpost wiki
Line 21: Line 21:


* handle a broad spectrum of digital content
* handle a broad spectrum of digital content
* quantify the ratings of digital content to a meaningful level
* quantify the ratings of digital content to a meaningful level, accounting for different personal taste
* account for different personal taste
* maintain content in a central collection
* maintain worthwhile content in a personal collection stored in a centralized location
* allow access to content from everywhere via a wide range of clients
* allow access to content from everywhere via a wide range of clients
* maximize client usefulness given client constraints (bandwidth, ui size, etc.)
* design clients based on client constraints (bandwidth, ui size, etc.)
* every client should always provide ability to rate content
* every client must always provide ability to rate content
* allow for introduction of new content with the greatest possible signal-to-noise ratio
* allow for introduction of new content with the greatest possible signal-to-noise ratio
* allow for safe removal of poorly-rated content


== Components ==
== Components ==

Revision as of 21:17, 15 September 2010


In the digital age, information flows.
Content is no longer controlled; it is created and released.
The old guard will fight to hold on to control.
The speed at which they lose control is the speed at which the digital age arrives.
The goal of this project is to accelerate progress towards the digital age.




Statement of Purpose

The purpose of The Digital Age project is to make peoples' lives simpler and more enjoyable by simplifying access to quality digital content, anywhere and everywhere.

Several specific requirements arise:

  • handle a broad spectrum of digital content
  • quantify the ratings of digital content to a meaningful level, accounting for different personal taste
  • maintain content in a central collection
  • allow access to content from everywhere via a wide range of clients
  • design clients based on client constraints (bandwidth, ui size, etc.)
  • every client must always provide ability to rate content
  • allow for introduction of new content with the greatest possible signal-to-noise ratio
  • allow for safe removal of poorly-rated content

Components

  • a central repository of media and corresponding metadata (mysql)
  • a server exposing a web services XML API to access the metadata (derived from ampache or MythShare)
  • the server also streams the media
  • a desktop client player (port hangthedj to qt, for pc/mac/linux) (also see amarok, sparklemedia, winamp, etc.)
  • a mediacenter player (mythmusic extended (previously known as MythDJ))
  • a mobile client player (tons of work being done - iphone - see iAmpache or this, android, palm webOS, blog)

The Roadmap

  • The Digital Age Software Manifesto
  • Metadata design
    • hasn't metadata structure already been designed and data collected? precanned music companies have this nailed down, I'm sure...
    • what about the last.fm API?
    • see current HTDJ db schema
      • DJ's
      • song ratings by DJ
      • current playlist
    • other ratings (movies, games, books)
  • Metadata access
    • Everything stored in a mysql database
    • Available via web service XML API (extended Ampache)
  • The Philanthropy Engine

More notes, to be organized...


       THE DIGITAL AGE SOFTWARE BUSINESS PLAN
       http://www.thedigitalage.org
       tdm_cvs_view/ShareTheDJ/docs/The Digital Age business plan diagrams.odg
       ------
       COMPARISON OF COMPONENT CHOICES
       ===============================
       HTTP-based traffic
           payload:
               boost::serialization 
               binary
               XML?  yuck
       Thick client
           cross-platform:
               mythweb + flex player                
           
           windows:
               htdj
           linux:
               mythfrontend
           palm:
               tcpmp
       Server options:
                                           
           Apache + custom mod             C++/boost, may be ugly to develop?
           EHS + STDJ                      C++/boost, far along, not robust/scalable?
           Apache + custom php             PHP, clean, lots of work? 
           Apache + custom MythTV          PHP, have to ramp up, prolly needs MythShare
           Apache + custom Ampache         PHP, Fat-client support difficult?
       PC client options:
           Mythfrontend (linux)            C++, MythShare plugin, fun!  Need MythWeb support for http.
           HTDJ (windoze)                  Far along, needs good HTTP client
           Browser + embedded player       Is flex mediaplayer ready?
           Browser + OS
       Palm client options:
           TCPMP + Blazer
           Custom TCPMP
       ===============================
       I am leaning towards:
           linux server
               Mythbackend
               Apache + MythWeb + MythDJ (use MDS?)
           linux client
               Mythfrontend/MythDJ
           windows client
               MythWeb/MythDJ + HTDJ
           palm
               Blazer + MythWeb/MythDJ download
               TCPMP playback
               SD card preload from MythWeb/MythDJ
           friend
               MythWeb/MythDJ + OS (VLC, etc.)
               MythWeb/MythDJ + embedded flash/flex2?
       ATTACK!!