fluid-work IRC Logs-2012-09-18

[08:29:54 CDT(-0500)] <Justin_o> cindyli: i'm working on the mock capture now.. do you think that the mock capture should respect the file name and directory parameters and try to copy the file to the specified location.. or do you think it should ignore them and just return the path to the mock captured image

[08:32:42 CDT(-0500)] <cindyli> I think the interface of the mock capture should be in sync with the real capture functions. Whatever parameters taken in by the real funcs should be applied to the mock too. Same rule applies if no parameters are presented in the real. what do you think?

[08:33:27 CDT(-0500)] <jhung> ^that would be good cindyli. That way we can manually test everything.

[08:33:41 CDT(-0500)] <cindyli> ya

[08:34:33 CDT(-0500)] <cindyli> Justin_o: ^

[08:38:05 CDT(-0500)] <Justin_o> cindyli: okay

[09:02:56 CDT(-0500)] <Justin_o> cindyli, jhung: the capture and multiCameraCapture functions are implemented in the mockCameraInterface

[09:03:09 CDT(-0500)] <jhung> Cool

[09:05:42 CDT(-0500)] <jhung> I just posted my 10-20 Sigma on Craigslist and Kijiji. $350.

[09:06:18 CDT(-0500)] <Justin_o> jhung: good luck

[09:10:51 CDT(-0500)] <jhung> Justin_o and cindyli: I should have a new mock-up for capture today.

[09:11:01 CDT(-0500)] <jhung> I also plan on getting calibration UI started.

[09:11:16 CDT(-0500)] <cindyli> thanks, jhung

[09:11:30 CDT(-0500)] <Justin_o> jhung: that's great

[09:50:46 CDT(-0500)] <alexn1> colinclark: I've added few tests to be sure that captions are not present in the HTML markup of a videoPlayer in some specific circumstances. Also I was a little bit horrified with some of the code I wrote there in tests so I rewrote them in a more conceivable way. They still pass and work fine. Although there are few tests which only could be ran from localhost since captionator attempts to read and parse the files from the file system.

[09:50:49 CDT(-0500)] <alexn1> colinclark: https://github.com/fluid-project/videoPlayer/pull/58

[09:56:20 CDT(-0500)] <colinclark> I will take a look

[09:59:11 CDT(-0500)] <alexn1> colinclark: thx

[10:19:25 CDT(-0500)] <cindyli> Justin_o, jhung_away, i noticed there's no jira for the implementation of the conventional URL handling. going to create one. Let me know if you know about any umbrella jira for this issue.

[10:20:37 CDT(-0500)] <Justin_o> cindyli: DECA-310

[10:20:58 CDT(-0500)] <Justin_o> cindyli: and i guess it's also related to DECA-308 and DECA-309

[10:21:29 CDT(-0500)] <cindyli> ah. ok. thanks, Justin_o

[10:28:02 CDT(-0500)] <cindyli> Justin_o: I merged in your code change, together with mine, pushed into my bitbucket branch

[10:28:12 CDT(-0500)] <cindyli> i will then working on conventional/capture

[10:28:48 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm trying to learn how to subclass dictionary so that we can get a similar interface but it will also manage a file on the filesystem

[10:29:51 CDT(-0500)] <cindyli> sounds a good strategy

[10:42:20 CDT(-0500)] <colinclark> yura2: Here's my and Kasper's so-called MASTERplan for Cloud4all over the next few months: http://piratepad.net/zc3sIT71nX

[10:42:32 CDT(-0500)] <yura2> colinclark: thanks

[10:43:02 CDT(-0500)] <colinclark> I think the biggest short-term task we need to find people to help with is the conversion to the new flat preferences structure

[10:43:26 CDT(-0500)] <colinclark> there will be some interesting challenges lurking behind that work, particularly how to "ontologize" flat preferences documents as part of the matchmaker

[10:43:45 CDT(-0500)] <yura2> hmm

[10:43:58 CDT(-0500)] <colinclark> I think we'll have to have some kind of semi-static document that represents different "world views" about the terms in the registry

[10:44:07 CDT(-0500)] <colinclark> That a matchmaker could consult when given a flat preferences document

[10:44:10 CDT(-0500)] <yura2> colinclark: by flat do you mean a structure where keys are paths ?

[10:44:16 CDT(-0500)] <colinclark> presumably, like anything else at the matchmaker layer, this would be configurable

[10:44:23 CDT(-0500)] <colinclark> yura2: Well, it's worse than that

[10:44:29 CDT(-0500)] <colinclark> properties are all currently URLs

[10:44:34 CDT(-0500)] <colinclark> generally meaningless URLs

[10:44:40 CDT(-0500)] <yura2> oh

[10:44:55 CDT(-0500)] <colinclark> It's not yet clear to me whether, with time, we'll be able to actually argue that these URLs, in spirit, are actually paths

[10:44:59 CDT(-0500)] <colinclark> like

[10:45:17 CDT(-0500)] <colinclark> http://gpii.net/registry/speechSynthesizerSpeechRate

[10:45:32 CDT(-0500)] <colinclark> becoming something morally equivalent to, say, "gpii.core.speechSynthesizerSpeechRate"

[10:45:38 CDT(-0500)] <colinclark> But then there's the added ontological question

[10:46:19 CDT(-0500)] <colinclark> how do we know, for example, that "having a speech rate" is a characteristic of, say, a "screen reader"

[10:46:33 CDT(-0500)] <colinclark> but also, distinctly, is a characteristic of a "reading aid" or something else

[10:46:39 CDT(-0500)] <colinclark> Do you see what I mean?

[10:46:45 CDT(-0500)] <yura2> hmm in my head i m thinking of this urls being restful

[10:46:54 CDT(-0500)] <colinclark> They won't be, ultimately

[10:47:03 CDT(-0500)] <colinclark> This is one of the weak areas of the Semantic Web

[10:47:12 CDT(-0500)] <colinclark> They've evolved to think about URLs as "URIs"

[10:47:22 CDT(-0500)] <colinclark> Meaning, they're identifiers, but they don't necessarily locate a Resource

[10:48:06 CDT(-0500)] <colinclark> I think in practice, things in the Registry will be legitimate, if not-very-useful, URLs

[10:48:15 CDT(-0500)] <colinclark> in the sense that the URL will look up to some metadata about the term itself

[10:48:27 CDT(-0500)] <yura2> oh ok

[10:48:38 CDT(-0500)] <colinclark> Anyway, in the previous ISO 24751, there was an ontology baked right in to the standard

[10:49:00 CDT(-0500)]

[10:49:03 CDT(-0500)] <colinclark> if you see what I mean

[10:49:14 CDT(-0500)] <yura2> yes

[10:49:15 CDT(-0500)] <colinclark> In this new manifestation, the ontology is gone

[10:49:30 CDT(-0500)] <colinclark> and we need to bind to an ontology (or not) based on the particular task we're doing

[10:49:38 CDT(-0500)] <colinclark> So, the key instance right now is our Canopy Matchamker

[10:49:50 CDT(-0500)] <colinclark> which performs a CSS-style ranking of matches based on specificity

[10:49:56 CDT(-0500)] <yura2> yes

[10:49:58 CDT(-0500)] <colinclark> where matches at "deeper" paths are rated more highly

[10:50:09 CDT(-0500)] <colinclark> once we switch to flat preferences, there will be no sense of depth

[10:50:14 CDT(-0500)] <colinclark> so that will have to come from an ontology

[10:50:35 CDT(-0500)] <yura2> right

[10:50:36 CDT(-0500)] <colinclark> At the moment, I'm imagining that the Ontologies (there are currently two) will periodically seed a "static" database

[10:50:48 CDT(-0500)] <colinclark> The two ontologies: one about users and the other about solutions

[10:51:24 CDT(-0500)] <colinclark> So in the latter case, Kostas' ontology would seed information about Solutions (including, potentially, model transformation rules) into the Solutions Registry database

[10:51:54 CDT(-0500)] <colinclark> I guess in the other case--the preferences document, it's not quite as simple

[10:52:20 CDT(-0500)] <colinclark> these "characteristics" will likely have to be stored in the preferences document itself

[10:52:33 CDT(-0500)] <colinclark> in that I might need to say, as a user, that I need a screen reader, specifically

[10:52:33 CDT(-0500)] <yura2> colinclark: so that would not be part of the metadata that is looked up by the url ?

[10:52:54 CDT(-0500)] <colinclark> since, say, Read/Write Gold might not cut it for me, despite also having a speech synthesizer with a configurable speech rate

[10:52:57 CDT(-0500)] <colinclark> if you see what I mean

[10:53:10 CDT(-0500)] <colinclark> yura2: No, that metadata won't be part of the Registry, to the best of my knowledge

[10:53:28 CDT(-0500)] <colinclark> and even if it were, we'd need to know what particular "characteristic" of a solution that the user was interested in

[10:53:43 CDT(-0500)] <yura2> right

[10:53:44 CDT(-0500)] <colinclark> which category of solution they wanted, given a reference to "speechSynthesizerSpeechRate"

[10:54:05 CDT(-0500)] <colinclark> It implies that the tools that generate preferences documents will be ontology-aware

[10:54:19 CDT(-0500)] <colinclark> so I imagine that preferences documents will be divided into blocks

[10:54:24 CDT(-0500)] <colinclark> the flat preferences themselves

[10:54:38 CDT(-0500)] <colinclark> and, based on our discussions in Linz, another block describing the sources of preferences

[10:55:03 CDT(-0500)] <yura2> right

[10:55:06 CDT(-0500)] <colinclark> so, say, if the statistical matchmaker inferred the "speechSynthesizerSpeechRate" preference, there would be a block that tells us where that setting came from

[10:55:15 CDT(-0500)] <colinclark> and then lastly an "ontology" block

[10:55:32 CDT(-0500)] <colinclark> describing what categories these terms fit in to, from the user's perspective

[10:55:36 CDT(-0500)] <colinclark> in short, it's immensely more complex

[10:55:39 CDT(-0500)] <colinclark> and rocky terrian

[10:55:43 CDT(-0500)] <colinclark> terrain

[10:55:49 CDT(-0500)] <colinclark> as I think it through

[10:55:57 CDT(-0500)] <colinclark> does it make sense at all to you, yura2?

[10:56:36 CDT(-0500)] <yura2> colinclark: more or less yes

[11:00:32 CDT(-0500)] <colinclark> I'll be back before too long, on the office side of things

[12:48:35 CDT(-0500)] <sgithens> Bosmon yura2: What sort of use cases does the asyncronous request grade fill?

[12:48:54 CDT(-0500)] <Bosmon> Hi sgithens

[12:49:08 CDT(-0500)] <Bosmon> You can refer to the IRC logs of fluid-tech from yesterday for some initial discussion

[12:49:28 CDT(-0500)] <Bosmon> The most basic use case is that it allows us to have a configurable policy for dispatching errors encountered during I/O

[12:49:34 CDT(-0500)] <Bosmon> But there may well be other uses over time

[12:50:03 CDT(-0500)] <Bosmon> The user of the standard "when" operation from when.js needs to explicitly manufacture an error callback

[12:50:14 CDT(-0500)] <Bosmon> But their code probably isn't the most appropriate place to write this callback

[12:50:30 CDT(-0500)] <Bosmon> The ASYNCHRONOUS REQUEST GRADE allows the policy on the error callback to be held within IoC configuration

[12:50:35 CDT(-0500)] <Bosmon> There are a few ways of looking at this

[12:50:42 CDT(-0500)] <Bosmon> i) as a kind of CURRYING of the error callback argument

[12:50:55 CDT(-0500)] <Bosmon> ii) as a kind of declarative equivalent of an exception handler

[12:52:13 CDT(-0500)] <sgithens> I see (ii), but how is it like currying?

[12:52:15 CDT(-0500)] <Bosmon> Now the request component has an invoker named "when" mixed into it

[12:52:20 CDT(-0500)] <Bosmon> Which takes one less argument

[12:52:25 CDT(-0500)] <sgithens> oh

[12:54:16 CDT(-0500)] <sgithens> so, rather than provide a callback, do you provide a lookup to the stored handler?

[12:54:21 CDT(-0500)] <Bosmon> But this is just the beginning of a rich ecology of REQUEST GRADES

[12:54:54 CDT(-0500)] <Bosmon> In the future, the GRADE CONTENT of a request handler will be looked up from its routing information

[12:54:59 CDT(-0500)] <Bosmon> And different requests will have different grades

[12:55:40 CDT(-0500)] <Bosmon> In a sense, "dynamically", even though the routing information is static

[13:43:04 CDT(-0500)] <sgithens> Bosmon: Is it also part of the solution of generating exception stacks, or was that a different problem?

[13:47:21 CDT(-0500)] <Bosmon> sgithens - that is different

[13:49:13 CDT(-0500)] <Bosmon> Although in general the use of request components is positioned as an alternative to stack traces as a means of "localising a computation"

[14:24:25 CDT(-0500)] <Bosmon> yura2 has an issue in CSpace relating to the ChangeApplier

[14:24:53 CDT(-0500)] <Bosmon> Which I am now refusing to continue to talk about privately : P

[14:24:57 CDT(-0500)] <yura2> lol

[14:25:09 CDT(-0500)] <yura2> Bosmon: yes, so the issue is

[14:25:25 CDT(-0500)] <yura2> that source tracking wont help

[14:25:37 CDT(-0500)] <Bosmon> Well, let's give people a bit of context

[14:25:41 CDT(-0500)] <yura2> as the actual change is dont on a bigger chunk

[14:25:47 CDT(-0500)] <Bosmon> Here we have this: https://github.com/collectionspace/ui/pull/125/files

[14:25:50 CDT(-0500)] <yura2> yes

[14:25:58 CDT(-0500)] <Bosmon> Which is an attempt to propagate private fields through the ChangeApplier

[14:26:16 CDT(-0500)] <Bosmon> Right now this works "by accident", but in general you can't guarantee that the exact change objects pass through the system untouched

[14:26:26 CDT(-0500)] <Bosmon> Especially once I fix up "rebasing" a bit better for Justin_o

[14:26:47 CDT(-0500)] <Bosmon> In general, source tracking is the feature that should be used for this

[14:26:51 CDT(-0500)] <Bosmon> So, how do we know it won't work?

[14:26:54 CDT(-0500)] <yura2> Bosmon: well ok but why do i need to worry about the object being the same object

[14:27:09 CDT(-0500)] <Bosmon> yura2 - because otherwise there is no guarantee that your "silent" field will be preserved

[14:27:16 CDT(-0500)] <Bosmon> If the ChangeApplier doesn't know about it

[14:27:37 CDT(-0500)] <Bosmon> in general the ChangeRequests that go in are not necessarily the same ones that go out

[14:27:50 CDT(-0500)] <Bosmon> As you will already have seen in your SuperApplier work : P

[14:27:50 CDT(-0500)] <yura2> Bosmon: right

[14:28:02 CDT(-0500)] <yura2> actually

[14:28:14 CDT(-0500)] <thealphanerd> yura2: are you coming to the google for the mentor summit?

[14:28:15 CDT(-0500)] <yura2> the same rule will apply there as well

[14:28:30 CDT(-0500)] <yura2> thealphanerd: not sure

[14:29:35 CDT(-0500)] <yura2> so Bosmon, the path of changeRequest might actually be a valid path

[14:29:48 CDT(-0500)] <yura2> the one that's supposed to indicate user change

[14:29:58 CDT(-0500)] <yura2> only this initial model reconstruction is not

[14:30:17 CDT(-0500)] <Bosmon> yura2 - ok, so let's go back to the issue of why you think sources won't work

[14:30:39 CDT(-0500)] <yura2> because i might not know which one is a valid user change and which one is not

[14:31:23 CDT(-0500)] <yura> so this issue for example

[14:31:30 CDT(-0500)] <yura> the change request will have path like this

[14:31:37 CDT(-0500)] <yura> "fields.narrowerContext"

[14:31:49 CDT(-0500)] <yura> or rather "fields.narrowerContexts"

[14:31:51 CDT(-0500)] <Bosmon> Surely the entire purpose of the source tracker is to notate what is a valid user change and what isn't....

[14:32:44 CDT(-0500)] <yura> Bosmon: perhaps i m misunderstanding your meaning of a source tracker

[14:33:33 CDT(-0500)] <Bosmon> I'm meaning that extra field in change requests that the ChangeApplier does support

[14:33:41 CDT(-0500)] <Bosmon> That we put in for the videoPlayer work &c

[14:33:53 CDT(-0500)] <Bosmon> So, what about fields.narrowerContexts?

[14:34:44 CDT(-0500)] <yura> so it's in newer infusion ?

[14:34:49 CDT(-0500)] <Bosmon> Yes

[14:34:52 CDT(-0500)] <yura>

[14:34:53 CDT(-0500)] <Bosmon> Well

[14:34:56 CDT(-0500)] <Bosmon> It was sort of always there

[14:35:03 CDT(-0500)] <Bosmon> But it is better supported now

[14:35:06 CDT(-0500)] <yura> what is that field called ?

[14:35:48 CDT(-0500)] <Bosmon> Well

[14:35:54 CDT(-0500)] <Bosmon> Actually it is not in the changeRequest at all

[14:36:03 CDT(-0500)] <Bosmon> I realise now that was part of the reengineering

[14:36:19 CDT(-0500)] <Bosmon> Putting it in the actual requests meant you couldn't actually track it consistently

[14:36:29 CDT(-0500)] <Bosmon> It is now stored in a private threadLocal maintained by the ChangeApplier

[14:37:02 CDT(-0500)] <yura> so what do you suggest i do, since i cant update to latest at this point ?

[14:37:47 CDT(-0500)] <Bosmon> Well, that's awkward...

[14:39:54 CDT(-0500)] <Bosmon> It would be better to try to update

[14:40:06 CDT(-0500)] <Bosmon> Otherwise you may as well just continue with your hack, with a suitable comment

[14:40:12 CDT(-0500)] <yura> we are in code freeze

[14:40:12 CDT(-0500)] <Bosmon> That the impl should use source tracking when it is available

[14:40:18 CDT(-0500)] <yura> ok

[14:40:22 CDT(-0500)] <Bosmon> Well, you should certainly continue with the hack in that case

[14:40:25 CDT(-0500)] <yura> i think ill opt out for that

[14:40:34 CDT(-0500)] <yura> thanks

[14:47:50 CDT(-0500)] <thealphanerd> yura: let me know if you end up going… I'm right around the corner

[14:48:06 CDT(-0500)] <yura> thealphanerd: will do

[14:56:39 CDT(-0500)] <cindyli> Justin_o: I made the change in cameraInterface and pushed into my branch. also pushed in the new conventional class that was missed out in the last commit.

[14:57:37 CDT(-0500)] <Justin_o> cindyli: excellent thanks

[20:56:05 CDT(-0500)] <sgithens> evenin'