[videoPlayer] Fluid 4559 - Re-wiring the timeupdate event to control the timing for the updates on time progress and captions (#13)

[Antranig Basman]

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