Extending the Project - Early January Design Decisions

Jan 4, 2010 at 7:59 PM

Please see blog post "Extending the project" on my blog,  and then please post discussion as replies to this message.






Jan 5, 2010 at 6:33 AM

Hi Jesee,

Regarding on the blog post, I have two questions:

  1. With refer to your statement, 'Frame will support a “Location Reached” event that can be triggered by (among other things)', do you mean that the frame will fire the location reached event and other modules which understand this location reached event can respond accordingly?

    If your answer is yes, do you have any ideas what kind of modules will need this type of event?
  2. "each module will have its own configuration file", do you have any ideas what type of configuration/properties can be set for each modules? Will it be something like the style & theme, position, etc..? Besides, how the modules are going to load the config file? Will it be passed from the shell (or they will automically look for a configuration file from a specific Uri?


Jan 5, 2010 at 3:39 PM


Your questions reveal that I have violated my own design principles: "Do not let the design get ahead of what you know" -- The right answer is, of course, to design only for what we know we need, and keep the design open enough to extend as new needs emerge. To answer your qeustions specifically:

1. No, I worded that poorly.  What I meant was that we know that videos will want to signal a marker has been encountered, and I can imagine that other frame components might want to signal that something has happened that is equivalent (you've reached the 4th level of play in this game)... then I went off the track and speculated that this should be handled by the Frame. But that is absurd.  The Frame might be the place to handle this, but I can easily imagine that there is a base class or interface that the video and game support or that there is a separate class they both associate with, etc. etc.  So let's just strike that statement (which I will do by editing my message and referring to this discussion.

2. Here is where I really went over the edge. I totally retract this statement. Maybe it makes sense for each module to have its own configuration file, but we'll only know that once we have modules and we've worked with a single integrated configuration file (the manifest you have working). So let's please stay with the manifest until it is manifestly not working :-)