[13:55:59 CST(-0600)] <Bosmon> colinclark, michelled, anyone.... I've just realised that there is a serious flaw in my integration strategy, perhaps someone has some time to talk about it

[13:57:39 CST(-0600)] <colinclark> yes, momentarily

[13:58:36 CST(-0600)] <Bosmon> "Then Nasrudin crept past him and stole some fruit"

[13:59:13 CST(-0600)] <michelled> what is the flaw Bosmon?

[13:59:31 CST(-0600)] <Bosmon> So.... it is about "anti-jank" ....

[13:59:53 CST(-0600)] <Bosmon> This being, apparently, Alex Russel's word for "seethe", the tendency of a UI to jump on startup when it receives updates

[14:00:30 CST(-0600)] <Bosmon> The basic strategy of the integration is to link together the ChangeAppliers of the two different components, UIOptions and the videoPlayer

[14:00:49 CST(-0600)] <Bosmon> Certain changes that occur in one are broadcast into other, generally different changes in the other

[14:00:56 CST(-0600)] <Bosmon> When both of them are up and running, things are generally fine

[14:01:23 CST(-0600)] <Bosmon> But the problem is on startup - at least to simplify things SOMEWHAT, I have decided that uiOptions should start up first

[14:01:48 CST(-0600)] <Bosmon> In theory, we should be able to support any order, but deciding on one order and sticking to it should in theory make things more straightforward for the time being

[14:02:12 CST(-0600)] <Bosmon> So, as uiOptions goes through its early startup, it fetches its settings from the cookie, and then updates its model

[14:02:26 CST(-0600)] <Bosmon> During this time, the video players are probably not in existence yet

[14:02:40 CST(-0600)] <Bosmon> The idea was to take these changes and put them into a "bottled model"

[14:03:05 CST(-0600)] <Bosmon> So that when it comes time to start up a video player, this "bottled bit of model" can be merged into its options, and so when it starts up, it has exactly the options it should have

[14:03:20 CST(-0600)] <Bosmon> And then after startup, it is dynamically connected to the uiOptions and everything is fine

[14:03:28 CST(-0600)] <Bosmon> Now, this is fine, for all settings, other than the language setting.....

[14:03:58 CST(-0600)] <Bosmon> The issue with the language setting is, that given a language preference setting in UIO, it's actually impossible to tell what initial model state this corresponds to in a videoPlayer until AFTER IT HAS STARTED UP

[14:04:19 CST(-0600)] <michelled> why is that Bosmon?

[14:04:33 CST(-0600)] <Bosmon> So, this relates to our decision to move over to arrays indexes for model state in the video player, which I'm embarrassed to say I was indeed behind, and now I'm thinking was perhaps not a good idea

[14:05:01 CST(-0600)] <Bosmon> Since, for example, if the captions with language "en" are at index 1 in the array, it is that index which needs to go into the model state

[14:05:19 CST(-0600)] <Bosmon> But you can't know what that index is until the component starts up, and you can see what captions it has, and what that index position is

[14:05:37 CST(-0600)] <Bosmon> On the face of it, this seems to make straightforward approaches to avoiding "jank" impossible

[14:05:56 CST(-0600)] <Bosmon> Without, perhaps, interfering in the lifecycle of videoPlayer somehow, which I was very keen to avoid, in making a general mechanism for connecting models together

[14:06:31 CST(-0600)] <Bosmon> So, we could reform the models, which would I guess make this particular problem go away, but for a start, it will be pretty expensive reversing all the changes we have made, and what's worse, I can't imagine that this situation is hugely untypical

[14:06:55 CST(-0600)] <Bosmon> You can't ALWAYS expect to be able to refactor one or more components so that their model state is "naturally indexed" by the model state of the other

[14:07:33 CST(-0600)] <michelled> right

[14:07:44 CST(-0600)] <Bosmon> So this suggests we should leave the APIs of the 2 components the way they are, and think about what the least interference in the current situation is that might solve the problem

[14:08:41 CST(-0600)] <Bosmon> I mean, we could just plough ahead now, and just put up with the startup jank, which would at least get things working... but I think for the demo to "look good" and smooth is almost as high a priority as for it to work at all

[14:09:37 CST(-0600)] <michelled> well, I guess I disagree there - but I do agree that the jumping is quite bad

[14:10:29 CST(-0600)] <michelled> do you think it would be horrible to setup the component off screen and then show it?

[14:10:40 CST(-0600)] <Bosmon> Yes, I think so

[14:10:52 CST(-0600)] <Bosmon> And the even bigger issue is what is meant by "and then"

[14:11:44 CST(-0600)] <Bosmon> How do we actually know when this point has arrived.....

[14:12:29 CST(-0600)] <michelled> true

[14:13:56 CST(-0600)] <michelled> Bosmon: now that the transcripts and captions are hidden on startup, do you find the jank terrible?

[14:14:21 CST(-0600)] <michelled> let me rebuild the nightly so you can see it

[14:14:22 CST(-0600)] <Bosmon> Well, it's not so bad - but of course, once we do the integration, this will come back again : P

[14:14:38 CST(-0600)] <Bosmon> Given that the transcripts and captions will then move into the state selected by uiOptions on startup

[14:14:52 CST(-0600)] <michelled> yes

[14:16:52 CST(-0600)] <Bosmon> It seemed really desirable to solve this problem imposing no more conditions on the components than that i) they were components, ii) with models and appliers

[14:17:11 CST(-0600)] <Bosmon> But that doesn't seem to be possible

[14:42:34 CST(-0600)] <Bosmon> I think I thought of a possible way out

[14:42:45 CST(-0600)] <Bosmon> Using the transactional features of the changeApplier

[14:42:50 CST(-0600)] <Bosmon> This is what they were always meant for

[14:42:59 CST(-0600)] <Bosmon> And would add no additional semantic to the components, beyond their having changeAppliers

[14:43:23 CST(-0600)] <Bosmon> Although this is an overly complex and poorly test framework feature that I am somewhat suspicious of : P

[14:59:47 CST(-0600)] <Bosmon> I guess this still doesn't resolve the issue of how the component knows not to try to "render on init"

Browser not supported