Hi Antranig, Thanks for taking the time to share the thoughts and explain in such a detail.
Your suggestions have been applied. The pull request for this branch is ready for another round of review, https://github.com/fluid-project/videoPlayer/pull/13 Cheers! Cindy ________________________________________ From: Antranig Basman [[email protected]] Sent: 06 February 2012 06:26 To: Li, Cindy Cc: Fluid Work Subject: Re: [videoPlayer] Fluid 4559 - Re-wiring the timeupdate event to control the timing for the updates on time progress and captions (#13) Yes, an invoker tends to be the way we mostly do things like this, even if they aren't an amazingly elegant solution. More heavyweight kinds of parameterisation might be a small component - or more lightweight ones as some kind of event, if the semantics are suitable (in one part of the framework, the ARIA labeller, we now have a single example of a "unicast event" but this is mainly to avoid a dependence on the IoC framework in this low-level component). "Answers on a postcard" are still requested for a better solution than the invokers we have now... perhaps the best substantial improvement there might be in the medium term is just to have a less bulky syntax than the one we have now. For example, the following invoker basicInvoker1: { funcName: "test.componentWithInvoker.basicInvoker1", args: ["{test.componentWithInvoker}.options.someField"] }, might one day be written in a much more compact notation as basicInvoker1: "test.componentWithInvoker.basicInvoker1({test.componentWithInvoker}.options.someField)" This would actually be pretty straightforward change to the framework, if we thought that their bulkiness were the biggest problem with invokers. this kind of thing ultimately points to the value of ceasing to code directly in JavaScript at all, but instead in a "translated dialect" that compiles down to JavaScript (in the same mechanism as CoffeeScript) where these kinds of specially encoded strings that we see inside IoC blocks are a proper syntactic part of the language that can be checked in the IDE/editor. The other thing that can be said against invokers is that they are quite expensive to invoke - probably at least 100x slower than a traditional function call and at least 10x slower than firing an event. This isn't a problem in most applications, where one typically expects an invoker to be executed just once for each event serviced from a user action, but would be a really unacceptable penalty in a function called in some inner loop. Part of this is a simple "quality of implementation" issue, and another part of it is perhaps being able to have some special syntax which could mark whether the IoC resolution of an invoker is "static" and not expected to change after the first time it is executed. In this way, if we knew that the LOCATION of the arguments to an invoker didn't change, we could speed it up to roughly the speed of an event - and if we knew that in addition the VALUE of the arguments didn't change, we could speed it up to a normal function call. Sorry for this longwinded answer.... but this was partially to set the scene for the particular question, "Why might one not use an invoker for convertToMillis"? Given this is a function that might be called onload of a captions file for every line in it, this might indeed be a case where the performance characteristics of today's invokers might be inadequate. It's best just to watch such issues and see if they emerge in practice, but I just wanted to set the scene for thinking about "what kind of parameterisation should I use" type questions in today's framework.... On 02/02/2012 11:47, Li, Cindy wrote: > Hi Antranig, > >> js/VideoPlayer_captionLoader.js >> >> iv) Thanks for the improved commenting and returned public implementation >> for "convertToMilli". Where do such timestamps come from? Is it from one of >> the standard subtitle file formats? If so, this should be documented, and >> the conversion function parameterised in the component rather than hardcoded >> in the impl at lines 77 etc. > > Can you elaborate on "the conversion function parameterised in the component > rather than hardcoded in the impl"? Do you mean defining the conversion > function as an invoker? > > Thanks. > > Cindy _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
