> OK, first of all, I am not trying to co-design this with you in > detail. I just threw out ideas that I had thought about in the past. > Now, with that said, I agree properties are cleaner than query string > parameters. You just need to keep in mind that properties are not > available/set at init time, and producers need to be able to fail on > init to indicate they cannot handle the resource/argument given. So, > if you need some parameters at init time, we really only have URL > parts: scheme, query, and fragment. If you do not need the parameters > at init time, then use properties including prefixed properties that > target encapsulated services. In the context of some smart producer, > you might want something on the URL to indicate whether to do > something extraordinary before choosing to do something new and fancy > versus following an existing tried and proven path of logic. If a > smart, super producer that no longer resembles the old behavior of > loader for the simple cases is to become the new default for > MLT_PRODUCER, then it needs to be really solid, which means it may be > sitting in some incubating stage for a while to become trusted for the > new default. I hope that was clear; it was a bit difficult to explain.
Makes perfect sense. I'll take a stab at a proof of concept in a fork and have you review it before I do a full implementation. Thanks for your ideas. It saves me from learning things the hard way. ~BM ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
