On Thu, 2009-02-05 at 21:29 +0000, Andrew Church wrote: > I unfortunately don't have time to follow the full discussion at the > moment due to a family emergency, so let me just drop in a couple of > thoughts (apologies if they've already been brought up): > > - The GUI should absolutely be separate from the core. Tying them > together really does nothing except increase the probability of bugs > on both sides. > > - I'd suggest C/C++ is a bad idea for the GUI. Unlike the transcode > core, the GUI doesn't (or shouldn't) have to deal with low-level data > transformation, so the speed offered by C/C++ isn't a benefit; and in > this day and age, anyone who _doesn't_ have at least Perl and Python > installed deserves what they get. (: And for anyone who doesn't feel > like installing GTK+ or Qt or whatever GUI toolkit we use, we can just > add a --disable-gui option to ./configure (which is a good idea anyway > to support e.g. installations where transcode is used as a backend to > something else).
Hi, I think it's safe to say that what emerged from the discussion is the call for an emprovement for transcode as a processing backend. Once this in place, an (official) scripting-based frontend can be deployed. On that topic: I vote for python! :) But my main concern still remains as the thing that still scares me most is the widget-placing phase :\ BTW, I've to agree: powering (or investing into) the transcode's suitability as backend is sensible, and perhaps it's just the most natural evolution. So, I think the best short-term move is to revamp the socket protocol, enhancing or changing it where it's needed, and stabilizing it in order to be suitable for the purpose. I'm in doubt if the official external API has to be the socket protocol, or if it's better to wrap it using a (thin) C frontend library, which could easily be the foundation for a scripting language transcode module (e.g. the hypotetical pytranscode python extention module could be built upon libtcsocket instead of sending data directly on the socket). When designing the tcrund side-project, a transcode runtime control daemon which spawns transcode and let a remote machine control it through the network, I choose a XML-RPC interface between the daemon and the clients, for two reasons: 1. I (usually) don't like to invent yet another custom protocol 2. I had the desire to try to deal on with such protocol :) Well, the point is I think XML-RPC (or something similar, XML-based) could also fit for the official transcode interface. As far as I know, Dealing with transcode as processing backend is mostly a setup thing, consisting in an exchange of (relatively) few (relattively) big messages in order to configure the backend; once fired it up, the exchange is (or should) limited to a relatively rare status update, and sometimes a sporadic cancellation request come it out. So, the XML overhead should be negligible. Surely Joern has a much wider experience on that field, and I'd like to know his thoughts :) Of course, discussion welcome -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
