[dvd::rip] Poll: Cluster mode, please participate

Hiho,

I like to ask three little questions to cluster mode users because I'm 
about rewriting the engine and thinking about dropping less used 
features. Resp. I need to know if these are really less used ;)

If you're interested in the technical details resp. want to understand 
the background of my questions, read on after answering this (really) 
little questionary:

1. Do you run the dvdrip-master process on a different
   machine than the dvd::rip GUI?

   [ ] Yes    [ ] No

   If Yes,

   1.1 Is this really essential for you?

       [  ] Yes   [ ] No, it's just cool ;)

       If Yes,

       Why? _______________________________________

2. How often do you shutdown the dvd::rip GUI program while
   dvdrip-master is running?

   [ ] Always    [ ] Never   [ ] Sometimes

   Please give a short reason for your answer:

   ____________________________________________________

3. Is it a problem for you if a dvd::rip cluster would
   be controlled by the dvd::rip GUI program and not
   by the independent dvdrip-master daemon anymore?

   [ ] Yes    [ ] No

   If Yes

   Why? (if not said above already):

   ____________________________________________________

That's it ;)

Thanks.

-------------------------------------------------------

Background information:

I'm currently working on a major rewrite of the internal job execution 
engine in dvd::rip. Major advantages are:

  * more detailed graphical plan of all steps of a job
    including improved progress output
  * extensive control about the running process(es),
    e.g. pause and resume
  * cleaner internal API, major stuff factored out into
    an extra Perl library (non important for the end-user
    but for the programmer ;)

For the standard (non-cluster-) mode I'm nearly finished, everything 
works quite well and I'm comfortable with it ;)

Now I like to use the same engine for cluster mode - why having 
different approaches for nearly the same thing? The current architecture
of dvd::rip's cluster mode is a real "add on" to dvd::rip, with a new 
external process (dvdrip-master), an extra scheduler and some more 
redundant stuff (e.g. a different graphical user interface ;)

My idea is to make the cluster-mode the default (with no extra effort if
you're on a single machine, of course). This way you can schedule all 
dvd::rip jobs (not just transcoding, but e.g. WAV extraction or other 
stuff as well), and can distribute all kinds of jobs over the network. 
Using transcode's cluster mode will get an option, to increase 
transcoding of single titles - but we know, transcode's cluster mode has
some limits, e.g. A/V sync problems with some multi-framerate NTSC 
material. Making the cluster mode a dvd::rip default feature would help,
because you can use it to transcode different titles (not using 
transcode's cluster splitting) in parallel without extra effort.

But the current multi-process dvdrip-master architecture makes it 
difficult for me to implement that resp. it's a bit too complicated to 
make it the dvd::rip default. And with the new slim execution engine 
it's not necessary anymore.

So the cluster would be controlled by the dvd::rip GUI process, not by a
dvdrip-master daemon anymore. That means: you need to keep the GUI open
while the cluster is running. dvdrip-tet, dvd::rip's not yet finished 
text GUI, will support cluster mode as well, so you're at least not 
bound to X11.

So I think that's Ok for most use cases, but probably I'm wrong, that's
why I started this little poll here.

Thanks for your interest,

Regards,

Joern

-- 
sub i($){print$_[0]}*j=*ENV;sub w($){sleep$_[0]}sub _($){i"$p:$c> ",w+01
,$_=$_[0],tr;i-za-h,;a-hi-z ;,i$_,w+01,i"\n"}$|=1;$f='HO';($c=$j{PWD})=~
s+$j{$f."ME"}+~+;$p.="$j{USER}\@".`hostname`;chop$p;_"kl",$c='~',_"zu,".
"-zn,*",_"#,epg,lw,gwc,mfmkcbm,cvsvwev,uiqt,kwvbmvb?",i"$p:$c> ";w+1<<07
pgprNtEyaBqqc.pgp
Description: PGP signature