On Mon, 2008-08-11 at 11:31 +0200, Rene Herman wrote: > On 11-08-08 10:02, Rohit Sharma wrote: > > > What all possible use cases are there for multiple data stream? > > ( apart from spy wares and other destructive uses ) > > As in filesystem forks? The most convincing one I feel is video, or more > specifically A/V interleaving. Without forks you end up solving the same > problem a few hundred times in container formats (matroska, ogg, avi and > so on) with specialized tools needed for each. With filesystem forks the Define a generic API and provide a compatibility lib until all but one died. Problem solved. And you get a working prototype to move to kernel space later on (at least partially). BTW we have that for tar.gz/tar.bz2/zip/lha/StuffIt/... since ages and no one ever was really bothered enough to try to cleanup that "mess". Or implement support in the VFS for .tar/.tar.gz. > interleaving implementation is provided and lets you for example very > easily extract the soundtrack; or the multiple soundtracks for multiple > languages. And the subtitles. And ... The problem with that idea is that no problem is solved. The video and audio streams need additional meta-data like codec and perhaps codec-specific parameters, sample rates, language of the sound stream and subtitles and font/encoding of the subtitles[0] (and God knows what else). And I don't see a sane possibility to deliver these: - The codec types + params etc. are part of the sound/video file. Are the existing ones prepared for this? - an additional metadata stream: Who defines the format of that? - extended attributes: Not many FS (and/or tools) support them. Additionally more unsolved problems with multiple data stream are: - How are the different data streams addressed/accessed? * as a suffix to the filename: That may break existing files/apps. * as a suffix after a "/": That will probably break even more apps. * another parameter to open(2)? * another open2(2) system call? * an ioctl(2) on the fd to select a stream? - How do I get a list of the available data streams? see list of crazy ideas above. - support by the wide variety of other existing tools (e.g. cp, cat, tar, scp, ...). Do they operate per default on all data streams or do they keep the current "default" behaviour and operate on the "main stream" (or whatever is the default)? And where are the possible gains in the first place? Conceptually I consider the idea of "multiple data streams in one file" at least inelegant[1] because - most of the above questions are already answered since years by "use a directory for it" and/or "use tar/tar.gz/zip/lha/... for it". Or - even simpler - use a DVD image for it and get a menu for free. - pure application concepts, problems and implementation are pushed down into a lower layer where they simply don't really belong. - The concept of a file is actually completely destroyed as a "file" is niw "a piece of data". If you have more pieces, use a directory (or a hierarchy of directories) to group them. Meta-Information about the contents is delivered within the file or as part of the filename (which may be good or not but people and apps get used to it). Bernd [0]: OK, one can assume that UTF-8 is the way to go for the encoding. [1]: "wrong, rubbish and superfluous" apply also IMHO. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
