Le lundi 29 novembre 2010 05:36:50, David Baelde a écrit : > 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.
Word. I did not see the thread safeness issue there.. And, clearly, adding mutexes in every source's get is just not an option.. However, I can't help to remark that thread safety is also an issue in the current insert_metadata stuff: a telnet client operates from a different thread.. I will fix and generalize the existing code, then. > > 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. Any chance we could have: (x,y) = foo (...) ? > > 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). Well, for one thing, the harbor HTTP stuff is *not* easy to implement. It needs to return both HTTP and HTML stuff. I just finished an example with a full php run as CGI and it was a pain. I think the documentation should make it clear: harbor's HTTP support is certainly not meant for a frontend. The good use would be to have a simple admin/cached backend to get/set values in a running script. I will write this loud and clear in the (coming) documentation.. Romain ------------------------------------------------------------------------------ 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
