Difference between revisions of "Dmmdb Braindump"
(→Development & Community) |
(→About javascrip) |
||
| Line 47: | Line 47: | ||
* webkist's inspector audit: nearly 100 of warning and problem on page's resources | * webkist's inspector audit: nearly 100 of warning and problem on page's resources | ||
| − | ==== About | + | ==== About javascript ==== |
* To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. | * To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib. | ||
* Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff. | * Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff. | ||
Revision as of 10:27, 19 August 2010
Note: This is a braindump, not a TODO, nor a roadmap. Just a loose collection of ideas for future releases of dmmdb.
Contents
Video Support
Supported Resolutions
All should be encoded with 1:1 pixel ratio and progressive scan
- LD: 240p - 320x240 4:3 and 432x240 16:9
- SD: 480p - 640x480 4:3 and 854x480 16:9
- HD basic: 720p - 1280×720 16:9 only
Support for 16:9 and HD is a good thing as it is a default feature nowadays in any cheapo camera, phone devices.
Audio Data Rates
- LD:
- SD:
- HD:
Video Data Rates
- LD:
- SD:
- HD:
Interface
Player
Size
Always set to 640px of width regardless of content. Which means that:
- video res is perfect match when it plays SD/480p material (default view)
- video res is stretched when it plays LD/240p material
- video res is reduced when it plays HD/720p content.
HD/720p is meant to be played in FS anyway, no need to have a bigger player for the page.
Default and Fall-back back-end
Only two back-ends are needed to cover almost all situations and simplify maintenance:
- default is HTML5 <video> tag
- fall-back is a GPL flash player (flow player is the most advanced but their GPL license is funny)
Development & Community
Code
Development
Using a DVCS would bring more visibility and simplify the process of contributing/deploying code. There are many options out there, from the popular git to mercurial or the more exotic darcs. By using DVCS, contributors can silently fork the project and commit locally to test different features and keep track of their development, once mature and accepted they can be pushed (repos to repos or as patches) to the official repos. Silent forkers can also keep in sync with the official repos while testing their changes. A central repos (such as gitorious) can be used as backup for official repos or hub if the workflow is classic (central repository).
Refactoring
The code needs a serious cleaning, at the time of this writing, on the kurimu channel page:
- W3C validator: 254 Errors and 38 warnings
- webkist's inspector audit: nearly 100 of warning and problem on page's resources
About javascript
- To simplify everything, each page should use XHTML and be kept as minimal as possible using as many js files as needed, so they can be tested independently and simplify maintenance and contrib.
- Jquery should be the only lib used and should be used as much as possible for all the heavy lifting for UI and AJAX stuff.
- Variable should be kept enclosed in functions whenever possible to avoid bad surprises when several channels are openned at once.
Community
Social software is growing fast and there are more and more efforts to provide distributed systems. It would be good to see how dmmdb can interface with, for example, GNU Social, FOAF, etc.
