Re: CD Writing Proposal

[Alban Browaeys <albanbrowaeys oreka com>]

>> > The user might want to write the same data more than once. Tying the
>> > 'disk' to a particular blank CD would be totaly artificial.
>> 
>> 	I'm not sure why this is a problem.  There are artificial abstractions
>> all over the place in computers.  A good abstraction helps users
>> understand the interface they are using.
 
> Because it makes it harder for the user to understand the process. It's
> illogical, so it's bad even for experienced users. It's also limiting
> posibilities.
> The concepts of a blank medium, a collection of data to be burned and an
> (iso) image should be kept intact. Blurring the lines will only lead to
> misunderstandings. The creation of a image can be hidden, but the fact
> that data is not just copied to disk not.

I bet you have summurized extrem cases: Either you bind desktop items to
hardware or virtualize hardware around data storage format.

Hardware point of view is cool as it removes any virtualization layer
keeping it simple ... for the expert. I do not expect to follow the blue
ray battle to know which format i should choose to make my iso (in case
this end up with a choose your destination disk type dialog). This is
simple but does not scale well. My opinion is it should be kept at
middleware level, like gnome-vfs/lufs or better mount.

Keeping close to data formatting scales better in the long run : whatever
blue disk, or whatever does not matter. Do i want a mode 2 iso, a cdplus,
... letting user choose destination medium and keeping track of conflicts.
Thus supporting a new medium won't require  a change in the "do we have a
four layer medium, this writer support only two so we are in trouble"
check size system. The actual splitting, format switch , compression of
the iso beore burning could be left as conversion mechanism while dragging
a data "image" to a cdwriter or blank disk icon.



Those all sound good . But hey do we want to burn cds or rawrite data
images ? I d love the process being left open for older/future needs. 
Having a *place* for backups, clip/film (avi, ogm are container not really
data formatting), audio album, photo album (does anyone still has a cdi
out there ?) , who knows ... would keep it to user world concepts. Those
being kept virtual the process would be as is:

User action - Editing level:
* Create video: this add a video virtual fs in which we can "symlink"
audio tracks and video (subtitles ?).
* Create backup/rescue (real backup as in "tar" for tapes, ghost for HDD)
: keep it virtual please, this could even be an hd image ripped on a cd
: with as small bootstrap to overwrite corrupted fs.
...


User publication: asking if we keep the draft or overwrite it with ending
result. 
 * video publication : a default to ogm/matroska (just
kidding avi) . Here we could tag audio track as en, fr. Border case as
managing conflict between video track format and those supported by the
container for advanced user using exotics formats/containers. Managing it
at this level is gracefull . In a hackish language this keep
implementation from bothering conceptual (video, backup) needs.
Plugins could then add ability to wrap video with a flash/director
navigation 
* backup: iso/joliet is obviously default with cd as target.

There really lay the format (iso, tar) vs hardware (cd,dvd)
dialog battle. In my opinion both fit well there . It s a moving target.
Splitting should occurs here : you need to know the destination medium .
Formats are not totally size agnostic, we need to know it at the same
level. Worst they are not medium free :  we could not split a video as is
to fit on two cds.

Egg or poultry . Why not egg in poultry ? Please use a new abstraction i
can t stand this pseudo easy sequential wizard where you have to ask your
son to find out where you are, go, will end up. 
I don t know may a perfect way . Classes of product are quite spread: can
i lend you a divx, a dvd . Seems users have already a solution to
the square circle paradox.
A class pool with divx, data cd, dvd, let user ability to derive
from that at will is exactly what we have in the theme manager. We often
use the same combination, even with poor default  it would not hurt. And
the default could evolve with user usage without rewriting core functions
in our application.
Asking the user to insert his medium to compute automatic defaults,
keeping distribution ones or providing advanced user with full choice. All
of them ?
The serial or anything else from the media should eventually be bundled to
the "product"


And finally user distribution : rawriting our images, burning data cd to
either . There we check serial against "product" or if missing against
medium size. This process as a Dnd of the "product" icon to the media  in
the workstation window.



... bullshit ! nautilus-cdburner is a cd burning tool. Sure but user don't
know burning , iso or even nautilus . We can not make a  cd burning app
simple. Nero is trying it for years and it s sure fun to use: popup with
cool icons, tons of progress bars, smily cds pictos. I won t say simple,
 fast and powerfull for anything more than bare minimum . To burn simply
 in the most used format and standard medium a 10 lines bash script with
 crecord/mkisofs beat it like hell.
Else one can forgot it s a burning app and take it as if cd is the best
medium today without hardwiring its gui on it.



Alban