XSPF Wish List: Difference between revisions
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 23:47, 21 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.