Yo, I agree that it isn't much code, but I think that it's important to find and follow good principles.
Moreover, small code changes can be trickier than it looks. For example, one thing I forgot to mention in my previous mail: Before your change, concerning encoded outputs, #insert_metadata was only called by the encoding process, which means that everything is in a single thread. I bet we relied on that assumption to avoid too many mutexes. Now that #insert_metadata is a general method that can be called anytime, we have to avoid new problems. On Mon, Nov 29, 2010 at 3:21 AM, Romain Beauxis <[email protected]> wrote: >> Think about it: why add #insert_metadata as a fundamental method for >> all sources, and not #on_track, #on_metadata, and even #on_blank, >> #map_metadata or #source_dynamic? To push the point even further, why >> not add support for instantiation for all variables and not only >> references? > > Well, why not :) For on_blank and source.dynamic, because it would be difficult as hell to do it efficiently and safely. > More seriously, I could also remark that we already have source.skip, > source.stop and other similar ones. There is a good reason why skipping is a core operation: we cannot implement it from the other operations. We could fast forward but it would not be efficient, require one clock per source, and in some cases might not even suffice -- skipping in sequence([sine(440.),sine(880.)]) goes to 880Hz, but fast forwarding stays on 440Hz. > It just looked more natural to me to have an operator of the type: > metadata -> source -> unit > for this because, intuitively, you "push" metadata. One you do (s,push) = insert_metadata(s) you have a push function of the right type. It's only a little worse than that because we still need to use those damn fst/snd functions for pairs. > On the contrary, on_metadata and the like are callbacks so the current API > makes more sense. I think the key difference is that we wrap instead of modifying in place. It creates important differences in the same way for insert_metadata, map_metadata and on_metadata: if you don't "pump" the wrapped source, nothing happens. This sounds bad but the bright side of it is that the initiale source is still untouched, so you can use a version without insertion in one place and a version with inserted metadata in another place. Immutability isn't only to make the implementor's life simpler. > These are different changes. Support for in-script insert_metadata could be > used in many different situations. Harbor stuff is just one way to use it -- > and > other. For instance, one thing that is possible now is to use harbor's HTTP > GET/POST to implement a JSON/AJAX-based callback to get the current metadata, > which I am sure will be useful to our users. If you give this to harbor users, don't you think other users will be jealous, and that we might even see people using harbor only for the custom HTTP requests? From a design viewpoint, I think it'd make sense to compare with other approaches, such as a lightweight external web server (using ruby, python, ocsigen or (fast)cgi scripts) that calls into our existing server infrastructure (probably renewed with a better JSON syntax). Cheers, -- David ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Savonet-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
