Event Handling and Configuration

Coordinator
Dec 3, 2009 at 6:07 PM
Edited Jan 3, 2010 at 7:09 PM

Please reply to this message with discussion relating to event handling, links, configuration files.

Dec 29, 2009 at 5:01 AM

Hi Jesse,

While reading you blog post on the MarkerEventHandler (MEH) I couldn't help but think of the Event Aggregator component of PRISM. I know you have mentioned PRISM as a possibility on later versions of the HVP, but the Event Aggregator seems like such a natural fit for Option 2 that it may deserve consideration.

Since PRISM is so modular, the player could limit itself to just that feature, and it would save some coding work. (Although using Unity as an IoC also comes to mind.)

Using the aggregator is really simple and the publisher/subscriber model opens the door for unforeseen expansion and enhanced uses for the events.

Just an idea on the table.

David Mora

 

Coordinator
Dec 30, 2009 at 1:52 AM

David,

I had been leaning heavily towards using Ninject or Unity (probably Ninject) for IOC and Dependency Injection. Would your idea work just as  well with one of them? If not,  do you think you could put together a small proof-of-concept on your idea and also provide some figures on what the cost is in code-size wiykd be if we were to use Prism only for that?

Thanks!

Dec 30, 2009 at 6:19 PM

Ninject is just fine with me. I like it too.

I don't know how the Event Aggregator would work with it so, as you suggest, let me put something together (vary basic and wire-framy) to see what happens and what the added weight would be.

David

Coordinator
Dec 30, 2009 at 7:07 PM

David,

At the risk of making you crazy, let me report to you that I had a long conversation with Glenn Block today, and as a result, while I think Ninject may be the right IoC container should the need arise, I'm convinced that all we want to do for now can be handled by MEF.  The good news is that it is pretty easy to use EventAggregator with MEF, and in fact, Glenn is putting together an example that I'll post about quite soon (though if you need the example right away, I can arrange that.

 

 

Dec 30, 2009 at 7:42 PM

You can't make me any more crazy than I already am. ;)

There is no rush, but it would be great if I can get my hands on the example as soon as it is ready. I am just as excited about this part of the project as I am about the RIA part.

In the mean time, I'll review some of the MEF materials available on the Net.

David

 

Dec 31, 2009 at 6:41 PM

Hi Jesse,

I noticed that there is a task in the Kanban for exploring the EventAggregator as a possible EventHandler and is queued for the WL team. So, unless you think otherwise, I'll move on to something else. No biggie.

David

 

Coordinator
Jan 1, 2010 at 12:00 AM
I'm sorry this keeps happening. It is a function of startup... If there isn't something else of equal interest give me a call tomorrow or over the weekend:617-628-7954


-jesse
Tiny Phone; Tiny Message

On Dec 31, 2009, at 1:41 PM, "DavidQMora" <notifications@codeplex.com> wrote:

From: DavidQMora

Hi Jesse,

I noticed that there is a task in the Kanban for exploring the EventAggregator as a possible EventHandler and is queued for the WL team. So, unless you think otherwise, I'll move on to something else. No biggie.

David

Jan 1, 2010 at 2:27 AM

That's OK. It's a team effort and, as you say, shuffling is bound to happen at the beginning. Besides, a resource like WL should be utilized to the maximum benefit of the project while it lasts.

For now, I assigned myself to the Closed Captions. But if it gets moved around I would understand. Sooner or later we will all settle, I think.

David

 

Coordinator
Jan 3, 2010 at 6:02 AM

Mike Loynd asked if it is correct that 

  • The synchronization events;  interval events, marker reached, potentially other event.. would all be available via the Event Aggregator to all modules.

[JL] Pending my better understanding the Event Aggregator, I'd say yes

  • The links module would consume a module specific config file specifying the criteria and the links to display in the module.

[JL]  Yes, the links module will have its own config file that will match a place in the video with what link shoudl be displayed, and will also designate what happens if the user clicks on that link.  For example, it might say "when you get here, show this link, and if the user click on the  link, pause the current video and display the video at this url"

  • The module examines the events for criteria matching the config file and displays the links when approprioate.

[JL] We have identified 2 ways to approach this: with markers causing events, or with polling for position.  If we poll for position then we'll almost certainly not raise a general event at every position (that would mean firing 10 events per second, though that is certainly possible), but rather we'll probably have a thread that checks the position every 100ms and synchronously hands that position to a business object, perhaps named LinkManager.  I'd imagine that LinkManager would have read the config file and created an ordered collection of (say) LinkObjects where a LinkObject encapsulates three pieces of information: the amount of time that has to pass for the link to be active, how to display the link and what to do if the link is clicked.

[JL] When the LinkManager is given a tme (e.g., 2:27:058  - two minutes, twenty seven seconds and 58milliseconds) it looks at the earliest link in the list; if the time is past the LinkObject's trigger time, then the LinkManger uses the LinkObject to create an eventArgs object, fires the event and removes the LinkObject from the collection.

But I just made that up.

The TOC module will consume a module-specific config file specifying the links to display.  Clicking on a link will raise an event through the Event Aggregator, and the expected behavior would be that the video would seek to the topic.  

[JL] I think it is pretty similar to how the LinkManager works, except that in the case of the tocManager (a) we display all the toc links at the start of the video and (b) the behavior for clicking on a link is always to raise an event so that the player can seek to that position.

 

Jan 3, 2010 at 7:36 AM

During my exploration of Closed Captions, I nosed around the SMF source code and noticed that they use polling, to fire the MarkerReached event. Given that one can add markers to the media after it opens and before it starts playing, what is the benefit of the HVP having its own polling system?

A couple of things I noticed that may be possible reasons for duplicating the functionality would be:

  1. The period for the DispatchTimer used for the marker polling is hard-coded to 750ms. That is an unfortunate design decision; however, since the class is partial, it's not beyond fixing. (Or maybe asking the SMF team to make it a protected property/field?).
  2. The polling and marker search happen in the main thread, in a video with many markers this could be also a problem. It would be nice if CheckForReachedMarkers were a virtual method so that derived players can modify the behavior.

Is that why building a new polling system sounds attractive? Otherwise I don't seem to see the advantage. The player already has quite a bit of logic regarding poll-timer and marker management.

Just trying to understand the architectural considerations.

David

 

Jan 3, 2010 at 12:58 PM

Since we cannot predict all the sources or forms of data that will be used as triggers and we cannot predict all the modules that may consume these, I had envisioned using the event aggregator as a form of “synchronization bus” and the interval event being on that synchronization bus. Being non-technical, I don’t understand the performance issues of frequent events or examining these so may I offer a few use scenarios where the synch source, synch data or modules are different. I am not asking that they be addressed, but purely to open up the conversation beyond the core scenario.

· The content is blended, using some static document pages and some video. Some links may be triggered by a video position and some by navigating to a specific item in the TOC.

· A module displays diagrams or supporting images based on synchronization criteria.

· An experience is made up of more than one video file.

· A video file has legacy markers and others do not.

From: jliberty [mailto:notifications@codeplex.com]
Sent: Sunday, January 03, 2010 1:03 AM
To: Mike Loynd
Subject: Re: Architecture and Coding Issues [SilverlightHVP:77016]

From: jliberty

Mike Loynd asked if it is correct that

  • The synchronization events; interval events, marker reached, potentially other event.. would all be available via the Event Aggregator to all modules.

[JL] Pending my better understanding the Event Aggregator, I'd say yes

  • The links module would consume a module specific config file specifying the criteria and the links to display in the module.

[JL] Yes, the links module will have its own config file that will match a place in the video with what link shoudl be displayed, and will also designate what happens if the user clicks on that link. For example, it might say "when you get here, show this link, and if the user click on the link, pause the current video and display the video at this url"

  • The module examines the events for criteria matching the config file and displays the links when approprioate.

[JL] We have identified 2 ways to approach this: with markers causing events, or with polling for position. If we poll for position then we'll almost certainly not raise a general event at every position (that would mean firing 10 events per second, though that is certainly possible), but rather we'll probably have a thread that checks the position every 100ms and synchronously hands that position to a business object, perhaps named LinkManager. I'd imagine that LinkManager would have read the config file and created an ordered collection of (say) LinkObjects where a LinkObject encapsulates three pieces of information: the amount of time that has to pass for the link to be active, how to display the link and what to do if the link is clicked.

[JL] When the LinkManager is given a tme (e.g., 2:27:058 - two minutes, twenty seven seconds and 58milliseconds) it looks at the earliest link in the list; if the time is past the LinkObject's trigger time, then the LinkManger uses the LinkObject to create an eventArgs object, fires the event and removes the LinkObject from the collection.

But I just made that up.

The TOC module will consume a module-specific config file specifying the links to display. Clicking on a link will raise an event through the Event Aggregator, and the expected behavior would be that the video would seek to the topic.

[JL] I think it is pretty similar to how the LinkManager works, except that in the case of the tocManager (a) we display all the toc links at the start of the video and (b) the behavior for clicking on a link is always to raise an event so that the player can seek to that position.

Read the full discussion online.

To add a post to this discussion, reply to this email (SilverlightHVP@discussions.codeplex.com)

To start a new discussion for this project, email SilverlightHVP@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Coordinator
Jan 3, 2010 at 4:06 PM

David & Mike,

WRT the architectural decision to have a second polling thread: the arguments you suggest are strong, the driving reason however was that unlike you, I had not located the polling mechanism inside the SMF (!)  I'm none too happy with having two polling threads, but I'm also not happy that the frequency is hard coded, and I'm much (much!) less happy having it in the main thread.  I'm going to be working with the SMF folks so I'll bring this up right away. 

For now, I see two mechanisms we'll want to use a lot:

  • Marker Injection - a config file tells you where the links are, you inject markers to those places and respond to marker events. No polling, very efficient.
  • Polling for position - as explained above under LinkManager (dark red responses to Mike)

Duplicate polling

Given the concerns with the built in polling, I'd like to see the impact of creating our own polling mechanism, with the interval set in slhvpLayout.xml  - over time we may well decide to merge with the existing polling and we should certainly implement accordingly.

Triggers other than video position

Mike raises a good point, but whether we use polling or markers is not affected by his point that there may be other triggers. One example I can imagine that is outside the current design, but a very easy extension, is to trigger a marker-like event when an animation reaches a given point.  We'll want to make sure that our events have a shared interface and/or base class so that we can have events triggered by the design i described above, by marker events and by other event-types not yet imagnied.

- please see next reply for more on config files -

 

-jesse

Coordinator
Jan 3, 2010 at 7:11 PM

Posted a first cut at two configuration files to (a) solicit information from XML experts and (b) work on clarifying my thinking about links.

Looking forward to the feedback..... I think :-)

 

-j

 

PS: reset this discussion to the more limited topic

Jan 4, 2010 at 4:24 AM

Hi Jesse, referring to the config files, I have some questions and some suggestions as well:

slhvpTOC.xml

What possible value be put in the TOCEntries.TOC.Type? Currently, I see that there is on TOC.

slhvpLinks.xml

1. May be we can setup a priortiy value on the links so display in a desired order.

2. For "Linq Programming Animation", is it some kind of animation on top of the video?

3. I suggest we can specific how the Link can be shown up, currently I suggest everything to be popup using a childwindow.

Jan 4, 2010 at 7:19 AM

Besides, I think we may also allow people to use an image to represent a Table of Content in of the markers, it's more intuitive for people to navigate to a specific item.

Coordinator
Jan 5, 2010 at 4:42 PM

Please see the previous discussion about my getting too far out front on the design. To answer your specific questions:

  1.  I don't see having a slhvpTOC.xml or any of the other xml config files except the manifest for now
  2. Setting up a priority order is a great idea, though we may do this in a number of ways; I'd hold off until we have more working
  3. Link Programming Animation - sorry I was unclear in my idea: I meant an animation that is used to explain Linq programming (as an examlpe)
  4. I don't quite understand what you are suggesting be in a popup, but am interested
  5. The ida of an image map is great in itself and illustrates the idea of extensibility; once we have the Table of Topics, we should explore this.

Because it confuses issues, for now I'd get rid of the term "Table of Contents".  What I believe we have, at least for now, is something like this:


modules

Jan 12, 2010 at 5:34 PM

Hi Jesse,

About the severely decoupled configuration, I think I understand the general idea and like it, but here are some things where I lost some traction:

  • As we work out a domain dictionary, I hope these will become more clear, but right now, I see a location (as in LocationReached or LocationsList) as position in the currently running video (or media clip). My question is, where does TimeObject fit and how does it relate to locations?
  • The relationship between a frames and viewers is still a bit fuzzy to me.  In a previous post, there is a mention of a Reader creating instances of frames, so I imagine a viewer is a reader. From what I understood then, a viewer creates frames. Are frames say, user or custom controls, or packaged layouts of several controls/components? Is the player composed of several viewers? In other words, are the links list and the items list in the GUI different viewers?
  • I would assume that there has to be a master time-line setting the pace, like the director in an orchestra. I also assume that the currently playing video or media clip would provide such pace-making. Are those assumptions correct? I don't imagine that the video provides the timing, but the context of the timing. So, we have one or more polling timers that use the video current position as the timing standard. Again, is that how you see it?
  • Although we have several specialized types of events, the event manager would be oblivious to them. We would have a base class or interface from which all events derive or implement. Right? The event manager will then act as a proxy service between publishers and subscribers. Someone raises an event by telling the manager to do so (as you mention), and the event is broadcast to the all the subscribers. The publisher never knows who is listening to the events. (That is the architecture of PRISMs Event Aggregator.)
  • One statement says "When a Frame[ i]s instantiated it subscribes to HereAreTimeObjects, HereIsAnItem, SeekTo, and fires off ICareAboutTimeObjects." This is one my sticky points about HereIs "things" I see mentions about TimeObjects and Items. What are the differences?
  • What is the function of the ICareAbout "thing" events?
  • Finally, I am partial to the Closed Captions module since it's my assigned task. From what I read so far, it would be a LocationsList module because it produces a list of locations of which it wants a notification when they are reached. It also would be a Frame because it shows data associated with the video. Does that make sense?

 

Sorry for the long list. Like I said, the gist of the configuration is clear and I like it, but some of the details are bit nebulous to me. I find that normal at this stage of the design, but maybe we need to clarify some of the semantics and start working a glossary or something.

Thanks,

David Mora