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> (smile)

[13:00:44 CDT(-0500)] <Bosmon> Hum

[13:00:49 CDT(-0500)] <Bosmon> I'm not sure that is good enough (smile)

[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 (smile)

[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 (smile) ?

[13:19:13 CDT(-0500)] <yura> with test (smile)

[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 (sad)

[13:21:57 CDT(-0500)] <Bosmon> Well, I think it is a great "object lesson" (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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