fluid-tech IRC Logs-2012-09-17
[12:55:32 CDT(-0500)] <Bosmon> yura - looking at your PUL request now
[12:55:42 CDT(-0500)] <Bosmon> What is the idea behind supporting multiple simultaneous strategies?
[12:58:44 CDT(-0500)] <yura> Bosmon: this is what i was thinking for Supporting Multiple Matchmakers To Do List
[12:58:53 CDT(-0500)] <Bosmon> Yes
[12:58:56 CDT(-0500)] <yura> where implementors/contributors
[12:59:14 CDT(-0500)] <yura> would write these strategies rather than whole new matchmakers
[12:59:17 CDT(-0500)] <Bosmon> Yes
[12:59:25 CDT(-0500)] <Bosmon> But how could they contribute more than 1 to be active at a time?
[12:59:25 CDT(-0500)] <yura> "pluggable" strategies
[13:00:33 CDT(-0500)] <yura> my feeling is - somehow
[13:00:33 CDT(-0500)] <yura>
[13:00:44 CDT(-0500)] <Bosmon> Hum
[13:00:49 CDT(-0500)] <Bosmon> I'm not sure that is good enough
[13:00:54 CDT(-0500)] <yura> well ok
[13:00:57 CDT(-0500)] <Bosmon> Can you directly think of a way? : P
[13:01:24 CDT(-0500)] <yura> so assuming by using a single strategy you will built a single list of directives
[13:01:58 CDT(-0500)] <yura> settings and lifecycle actions
[13:02:17 CDT(-0500)] <yura> so by using multiple strategies
[13:02:41 CDT(-0500)] <yura> we can we can somehow combine them all together
[13:02:55 CDT(-0500)] <yura> based on some sort of mechanism
[13:03:01 CDT(-0500)] <yura> priority or what not
[13:03:19 CDT(-0500)] <yura> perhaps one precedes the other
[13:03:26 CDT(-0500)] <yura> in a meaningful way
[13:10:19 CDT(-0500)] <yura> so what do you think Bosmon
[13:10:30 CDT(-0500)] <yura> is there a potential for such a thing /
[13:10:30 CDT(-0500)] <yura> ?
[13:10:36 CDT(-0500)] <Bosmon> I'm not sure I see one
[13:10:51 CDT(-0500)] <yura> you think there's no such usecase ?
[13:10:59 CDT(-0500)] <Bosmon> Since the output of a matchmaker is not like the input - and they are contributed by different parties, who in theory have no knowledge of each other
[13:11:07 CDT(-0500)] <Bosmon> So I see no "natural" way to combine the output of different strategies
[13:11:17 CDT(-0500)] <yura> well wait
[13:11:22 CDT(-0500)] <yura> matchmaker contains strategies
[13:11:33 CDT(-0500)] <Bosmon> Well... it used to contain one strategy
[13:11:35 CDT(-0500)] <yura> each strategy would have the same signatur no
[13:11:42 CDT(-0500)] <yura> yes yes
[13:11:46 CDT(-0500)] <Bosmon> yes
[13:11:51 CDT(-0500)] <yura> so matchmaker itself would know
[13:11:53 CDT(-0500)] <Bosmon> There is one signature for strategies
[13:13:14 CDT(-0500)] <yura> yes
[13:13:30 CDT(-0500)] <yura> and matchmaker match returns the same thing
[13:15:10 CDT(-0500)] <Bosmon> Well, they return solutions, to be sure
[13:15:20 CDT(-0500)] <yura> yes
[13:15:26 CDT(-0500)] <Bosmon> But there seems to me to be no natural semantics where the outputs of different strategies are "accumulative"
[13:15:27 CDT(-0500)] <yura> and then once passed through transformer
[13:15:34 CDT(-0500)] <Bosmon> Should they accumulate with "and" or with "or", for example?
[13:15:49 CDT(-0500)] <Bosmon> Every previous stage has acted by reducing the number of solutions
[13:15:57 CDT(-0500)] <yura> well good question
[13:16:07 CDT(-0500)] <Bosmon> And because there are no such natural semantics, I think this is why there are no good grounds for allowing them to accumulate at all
[13:16:15 CDT(-0500)] <Bosmon> At least, within the matchmaker's own code
[13:16:23 CDT(-0500)] <yura> so lets say they strategies can support priorities
[13:16:30 CDT(-0500)] <Bosmon> It would be perfectly possible for a 3rd party to draw upon other matchmakers and do the accumulation in their own code
[13:16:40 CDT(-0500)] <Bosmon> Well they can - be we have no design mandate for this!
[13:16:45 CDT(-0500)] <Bosmon> And no clear goals
[13:17:05 CDT(-0500)] <Bosmon> I think all we need to do for the time being is just support one, pluggable, possibly asynchronous strategy
[13:17:51 CDT(-0500)] <yura> well ok
[13:18:05 CDT(-0500)] <yura> so the whole task then reduces to promisising the strategy resolution ?
[13:18:10 CDT(-0500)] <Bosmon> Yes, I think so
[13:18:28 CDT(-0500)] <yura> pfft ok
[13:18:55 CDT(-0500)] <yura> thanks for walking through this
[13:19:11 CDT(-0500)] <yura> will you have a chance to take a look at other 2 pull requests ?
[13:19:13 CDT(-0500)] <yura> with test
[13:19:13 CDT(-0500)] <Bosmon> No problem - sorry to have a "simplifying answer" : P
[13:19:17 CDT(-0500)] <Bosmon> Yes, I will look at them shortly
[13:19:23 CDT(-0500)] <yura> great
[13:19:33 CDT(-0500)] <yura> ill update this one
[13:19:38 CDT(-0500)] <yura> in the meanwhile
[13:19:39 CDT(-0500)] <Bosmon> The couch/datasource promise work looks good, except for one small unnecessary use of the framework
[13:20:00 CDT(-0500)] <yura> i did it to impress you
[13:21:57 CDT(-0500)] <Bosmon> Well, I think it is a great "object lesson"
[13:22:20 CDT(-0500)] <yura> http://cdn.memegenerator.net/instances/400x/26885901.jpg
[13:22:30 CDT(-0500)] <Bosmon> It probably deserves commenting to the wider community since it is an interesting answer to the question, "Is it always better to use the framework for a task if you can?"
[13:22:57 CDT(-0500)] <Bosmon> Clearly we designed the framework to be used, but if it were used in every case where it COULD be used, it would become unusable : P
[13:23:05 CDT(-0500)] <Bosmon> If that doesn't seem paradoxical : P
[13:23:29 CDT(-0500)] <Bosmon> But yes, it should only be used in cases where the resulting code either has a clearer workflow, or becomes shorter, or preferably both
[13:23:31 CDT(-0500)] <yura> haha
[13:23:34 CDT(-0500)] <yura> just like my mme
[13:23:36 CDT(-0500)] <yura> meme
[13:23:51 CDT(-0500)] <Bosmon> wow, you made your own meme : P
[13:24:02 CDT(-0500)] <yura> haha
[13:24:06 CDT(-0500)] <yura> you are impressed NOW
[13:24:10 CDT(-0500)] <Bosmon> Is this a Russian person?
[13:24:14 CDT(-0500)] <yura> no us
[13:24:25 CDT(-0500)] <Bosmon> Oh yes, I see now
[13:24:30 CDT(-0500)] <yura> it's fairly new, from the olympics
[13:26:58 CDT(-0500)] <Bosmon> I'm wondering why you remove the couch fields from the response?
[13:27:09 CDT(-0500)] <Bosmon> Hi there colinclark
[13:27:20 CDT(-0500)] <Bosmon> We have been having an interesting discussion about yura's matchmaker things
[13:27:27 CDT(-0500)] <Bosmon> You may want to look up in the BOTT
[13:27:39 CDT(-0500)] <Bosmon> And see if you think my conclusion is reasonable
[13:27:56 CDT(-0500)] <Bosmon> Or colinclark_ for that matter
[13:28:04 CDT(-0500)] <colinclark_> I'll do that
[13:39:05 CDT(-0500)] <yura> Bosmon: https://github.com/GPII/universal/pull/52/files
[13:41:49 CDT(-0500)] <Bosmon> Looks good - can we perhaps convert the use of the error callback into a piece of framework?
[13:42:01 CDT(-0500)] <Bosmon> Always think when you write a piece of code - what would happen if someone cut and pasted this
[13:44:31 CDT(-0500)] <Bosmon> yura ^
[13:44:56 CDT(-0500)] <yura> alright
[13:45:00 CDT(-0500)] <yura> will do
[13:49:14 CDT(-0500)] <Bosmon> Cheers
[13:49:19 CDT(-0500)] <Bosmon> What scheme do you think you will use?
[14:04:49 CDT(-0500)] <yura> Bosmon: ^ that's for me ?
[14:05:31 CDT(-0500)] <Bosmon> yes
[14:06:12 CDT(-0500)] <yura> you mean scheme for converting the errback into framework ?
[14:09:30 CDT(-0500)] <Bosmon> yes
[14:11:03 CDT(-0500)] <yura> i m thinking maybe a thing called gpii.when ?
[14:11:24 CDT(-0500)] <yura> that will add an errback
[14:11:29 CDT(-0500)] <Bosmon> Yes
[14:11:42 CDT(-0500)] <Bosmon> That is one valid approach
[14:11:55 CDT(-0500)] <yura> what other ones were you thinking ?
[14:12:05 CDT(-0500)] <Bosmon> Another one would simply be to allow easier access to the errback itself
[14:12:21 CDT(-0500)] <Bosmon> Probably gpii.when is more workable
[14:12:26 CDT(-0500)] <Bosmon> Well
[14:12:30 CDT(-0500)] <Bosmon> Not necessarily
[14:12:58 CDT(-0500)] <Bosmon> The only facility we stand to lose from the standard "when" is this "progress callback"....
[14:13:15 CDT(-0500)] <yura> which is not part of the spec anyways
[14:13:52 CDT(-0500)] <Bosmon> ok
[14:14:19 CDT(-0500)] <Bosmon> We also have to bear in mind that our error strategy is not fully mature
[14:14:36 CDT(-0500)] <Bosmon> In the fullness of time, the component that we fire the event on may not necessarily be the requestProxy itself
[14:14:46 CDT(-0500)] <Bosmon> But may be the current component itself
[14:15:35 CDT(-0500)] <Bosmon> In any case, use of the global value "when" is sort of unsightly
[14:15:45 CDT(-0500)] <Bosmon> So I think the gpii.when approach definitely has some legs
[14:15:57 CDT(-0500)] <Bosmon> But to be stable, it will need to have some "invoker-like" aspects
[14:16:11 CDT(-0500)] <Bosmon> In that it should be able to tell what the current position in the component tree is
[14:17:01 CDT(-0500)] <Bosmon> I am thinking that a good approach might be to supply a "mixin grade" to this component
[14:17:23 CDT(-0500)] <Bosmon> Which mixes a method named "when" onto the current component
[14:17:34 CDT(-0500)] <Bosmon> This grade has a "default configuration argument" which resolves onto requestProxy
[14:17:48 CDT(-0500)] <Bosmon> but which the user can override to point the error target event onto a different component if necessary
[14:18:04 CDT(-0500)] <Bosmon> Well, the grade may as well just contain a description for an invoker named "when"
[14:19:30 CDT(-0500)] <yura> ok ill need to read this a couple of times
[14:19:35 CDT(-0500)] <yura> and then get it wrong a couple more
[14:20:03 CDT(-0500)] <yura> but i think what you are saying makes sense
[14:20:17 CDT(-0500)] <Bosmon> That's fine - I think this could be a promising start on our "request grade architecture" too
[14:20:24 CDT(-0500)] <yura> ys
[14:20:27 CDT(-0500)] <Bosmon> It's just exactly the kind of behaviour we will want more generally
[14:20:59 CDT(-0500)] <yura> anything about the promise wrapper pull request /
[14:21:00 CDT(-0500)] <yura> ?
[14:21:51 CDT(-0500)] <Bosmon> I think just with the "extra use of framework" removed, it can go in
[14:22:02 CDT(-0500)] <yura> wait i think that was couch one no ?
[14:22:27 CDT(-0500)] <yura> ok then ill update those two and will continue GPII049
[14:22:29 CDT(-0500)] <yura> 40
[14:22:34 CDT(-0500)] <Bosmon> Well, those may as well go together
[14:22:41 CDT(-0500)] <Bosmon> Since they are cumulative
[14:23:10 CDT(-0500)] <Bosmon> I think your tests could be condensed though
[14:23:16 CDT(-0500)] <Bosmon> I think I mentioned this before I went away
[14:23:59 CDT(-0500)] <yura> you mentioned it about the infusion pull request
[14:24:04 CDT(-0500)] <Bosmon> Oh
[14:24:13 CDT(-0500)] <Bosmon> of course, sorry
[14:25:06 CDT(-0500)] <Bosmon> I'm just looking at your "addToEnvironment" utility
[14:25:47 CDT(-0500)] <Bosmon> It looks a bit peculiar... can you describe the reason for it?
[14:25:56 CDT(-0500)] <yura> yes
[14:25:59 CDT(-0500)] <yura> the reasno is
[14:26:14 CDT(-0500)] <yura> that i might have something not there when i create a test environment
[14:26:22 CDT(-0500)] <yura> something that the component in test requires
[14:29:14 CDT(-0500)] <yura> so in your comment for GPII-16
[14:29:26 CDT(-0500)] <yura> which part of framework use are you talking about ?
[14:30:07 CDT(-0500)] <Bosmon> The use of model transformation
[14:30:14 CDT(-0500)] <Bosmon> To copy 2 values from one block of JSON to another
[14:30:18 CDT(-0500)] <yura> the one that is deleted ?
[14:30:51 CDT(-0500)] <Bosmon> Now I'm completely confused....
[14:31:10 CDT(-0500)] <Bosmon> How could it be deleted if we never had this capability.......
[14:31:27 CDT(-0500)] <yura> of course we had
[14:31:36 CDT(-0500)] <yura> but which capability are you talking about
[14:31:48 CDT(-0500)] <yura> transforming _rev into rev ? and _id into id ?
[14:31:57 CDT(-0500)] <Bosmon> Of a couchDB-aware dataSource
[14:32:45 CDT(-0500)] <yura> now i m confused
[14:32:54 CDT(-0500)] <yura> there's no use of model transformation there any more
[14:32:56 CDT(-0500)] <Bosmon> Ok... so you had already spontaneously got rid of the model transformatioN!
[14:33:06 CDT(-0500)] <yura> the only cure thing i m using is on line 244
[14:33:19 CDT(-0500)] <Bosmon> Yes
[14:33:21 CDT(-0500)] <yura> which is filterKeys utility
[14:33:31 CDT(-0500)] <Bosmon> I had asked about that too - why do we want to get rid of these elements from the document?
[14:33:50 CDT(-0500)] <yura> because that's the whole point of couchdb data source
[14:34:08 CDT(-0500)] <yura> it will handle all couch specific stuff internally
[14:34:18 CDT(-0500)] <yura> the user will only get and set the data as they know it
[14:34:23 CDT(-0500)] <Bosmon> Well, I guess this part of that is an implementation decision
[14:34:26 CDT(-0500)] <yura> without the need to be aware of id rev
[14:34:27 CDT(-0500)] <Bosmon> Which could be taken in 2 ways
[14:34:47 CDT(-0500)] <Bosmon> One way is to embed the "real document" at a nested path... so that the keys never collide
[14:35:04 CDT(-0500)] <Bosmon> The other way is to still automatically update id and rev, but still to show them to the user
[14:35:29 CDT(-0500)] <Bosmon> It's not impossible that SOMEONE may be interested in reading them, as a "subsidiary user", even if the "direct user" doesn't want to have to update them
[14:35:35 CDT(-0500)] <Bosmon> So the current strategy seems a bit mixed
[14:35:43 CDT(-0500)] <Bosmon> In that the keys could still conceivably interfere, but the user doesn't get to see them
[14:35:54 CDT(-0500)] <yura> well ok
[14:35:58 CDT(-0500)] <yura> i m looking at it this way
[14:36:09 CDT(-0500)] <yura> is id and revision in any case part of user preferences lets say
[14:36:19 CDT(-0500)] <yura> i think not
[14:36:36 CDT(-0500)] <yura> it's just the implementation artifact of our data store
[14:36:53 CDT(-0500)] <Bosmon> Yes
[14:37:03 CDT(-0500)] <Bosmon> I think in that case we should follow the "embedding" strategy
[14:37:12 CDT(-0500)] <Bosmon> And put the entire user document at a nested path
[14:37:27 CDT(-0500)] <Bosmon> If we want the "100% agnostic CouchDB DataSource"
[14:37:33 CDT(-0500)] <yura> i m not sure i understand what you mean by this
[14:37:49 CDT(-0500)] <Bosmon> Well, put the user's document within Couch's document at a name "value" or "document" say
[14:38:01 CDT(-0500)] <Bosmon> So that we are quite sure that rev/id can never conflict with the user's own properties
[14:38:35 CDT(-0500)] <yura> and then just return set value ?
[14:38:44 CDT(-0500)] <Bosmon> yes
[14:38:46 CDT(-0500)] <yura> ok
[14:38:50 CDT(-0500)] <yura> that makes sense
[14:39:00 CDT(-0500)] <yura> ill take care of it
[14:39:08 CDT(-0500)] <Bosmon> So you had already got rid of the use of modelTransformation by yourself earlier?
[14:39:14 CDT(-0500)] <yura> yes
[14:39:14 CDT(-0500)] <Bosmon> Have I been misreading the diff all this time?
[14:39:18 CDT(-0500)] <Bosmon> ok, cool
[14:39:19 CDT(-0500)] <Bosmon> Sorry
[14:39:26 CDT(-0500)] <yura> well in this pull request
[14:39:48 CDT(-0500)] <yura> but yes earlier than you comment
[14:39:51 CDT(-0500)] <yura> your
[14:39:56 CDT(-0500)] <Bosmon> great
[15:16:43 CDT(-0500)] <yura> Bosmon: https://github.com/GPII/universal/pull/51/
[15:18:47 CDT(-0500)] <Bosmon> yura - looks good - I will test and push
[15:19:08 CDT(-0500)] <yura> Bosmon: appreciate it