XSPF Wish List: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
(Request: track start and end attributes (seconds))
No edit summary
Line 8: Line 8:
* Request: Track creation & last modified dates
* Request: Track creation & last modified dates
* Request: track start and end attributes (seconds). example: for large video files the specification of ''start'' and ''end'' positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.
* Request: track start and end attributes (seconds). example: for large video files the specification of ''start'' and ''end'' positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.
* Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.

Revision as of 00:47, 22 May 2007

This page is a place to file requests for features for XSPF. Any kind of feature can be entered here, please don't be bashful.

  • Request: MIME type of linked media
    • This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.
    • Proposal: a new extension element defined as the result of a HEAD on the link.
  • Request: Semantics for M3U-like '#CURTRACK'
  • Request: Track creation & last modified dates
  • Request: track start and end attributes (seconds). example: for large video files the specification of start and end positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.
  • Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.