IRC log of dig on 2014-03-18

Timestamps are in UTC.

00:23:20 [scor]: scor (~scor@c-98-217-11-242.hsd1.ma.comcast.net) has joined #dig
00:23:21 [scor]: scor has quit (Changing host)
00:23:21 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
00:30:34 [scor]: scor has quit (Quit: scor)
00:36:14 [scor]: scor (~scor@c-98-217-11-242.hsd1.ma.comcast.net) has joined #dig
00:36:14 [scor]: scor has quit (Changing host)
00:36:14 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
02:20:55 [cheater__]: cheater__ has quit (Ping timeout: 264 seconds)
02:33:04 [cheater__]: cheater__ (~cheater@p57AE953F.dip0.t-ipconnect.de) has joined #dig
03:14:58 [scor]: scor has quit (Quit: scor)
03:18:39 [scor]: scor (~scor@c-98-217-11-242.hsd1.ma.comcast.net) has joined #dig
03:18:40 [scor]: scor has quit (Changing host)
03:18:40 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
04:24:44 [scor]: scor has quit (Quit: scor)
05:24:54 [timbl]: timbl has quit (Ping timeout: 255 seconds)
05:30:11 [timbl]: timbl (~timbl@207.194.238.3) has joined #dig
05:54:29 [timbl]: timbl has quit (Quit: timbl)
06:22:22 [bblfish]: bblfish has quit (Remote host closed the connection)
06:22:58 [bblfish]: bblfish (~bblfish@AAubervilliers-651-1-124-48.w86-198.abo.wanadoo.fr) has joined #dig
06:27:13 [bblfish]: bblfish has quit (Ping timeout: 240 seconds)
06:50:10 [melvster]: melvster has quit (Ping timeout: 246 seconds)
07:31:27 [cheater_1]: cheater_1 (~cheater@p57AE96F6.dip0.t-ipconnect.de) has joined #dig
07:34:43 [cheater__]: cheater__ has quit (Ping timeout: 264 seconds)
08:05:14 [jmvanel]: jmvanel (~jmvanel@123.0.88.79.rev.sfr.net) has joined #dig
09:31:37 [jmvanel]: jmvanel has quit (Ping timeout: 240 seconds)
09:34:49 [Sebastien-L]: Sebastien-L (~sebastien@host.214.33.23.62.rev.coltfrance.com) has joined #dig
10:03:06 [jmvanel]: jmvanel (~jmvanel@78.193.21.40) has joined #dig
10:40:41 [Sebastien-L]: Sebastien-L has quit (Ping timeout: 252 seconds)
10:47:18 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
10:53:30 [scor]: scor has quit (Quit: scor)
11:26:12 [Sebastien-L]: Sebastien-L (~sebastien@host.214.33.23.62.rev.coltfrance.com) has joined #dig
11:37:11 [scor]: scor (scor@nat/acquia/x-cdmrmuzxmkoafzng) has joined #dig
11:37:11 [scor]: scor has quit (Changing host)
11:37:11 [scor]: scor (scor@drupal.org/user/52142/view) has joined #dig
11:37:53 [scor]: scor has quit (Client Quit)
11:38:38 [Ralph]: Ralph (rswick@w3cvpn1.w3.org) has joined #dig
11:38:46 [Ralph]: Ralph is now known as RalphS
12:03:29 [scor]: scor (scor@drupal.org/user/52142/view) has joined #dig
12:09:31 [cheater_1]: cheater_1 has quit (Ping timeout: 264 seconds)
12:10:23 [cheater__]: cheater__ (~cheater@p57AE96F6.dip0.t-ipconnect.de) has joined #dig
12:43:53 [melvster]: melvster (~melvster@89.176.108.70) has joined #dig
13:22:00 [deiu]: deiu (~andrei@unaffiliated/deiu) has joined #dig
13:24:31 [Sebastien-L]: Sebastien-L has quit (Ping timeout: 264 seconds)
13:32:50 [jmvanel]: jmvanel has quit (Read error: No route to host)
13:32:50 [Sebastien-L]: Sebastien-L (~sebastien@host.214.33.23.62.rev.coltfrance.com) has joined #dig
13:54:22 [timbl]: timbl (~timbl@207.194.238.3) has joined #dig
14:00:52 [deiu]: Cimba screencast (with audio): https://www.youtube.com/watch?v=z0_XaJ97rF0
14:01:01 [timbl]: timbl has quit (Ping timeout: 246 seconds)
14:03:46 [jmvanel]: jmvanel (~jmvanel@78.193.21.40) has joined #dig
14:11:00 [timbl]: timbl (~timbl@207.194.238.3) has joined #dig
14:47:15 [bblfish]: bblfish (~bblfish@host.214.33.23.62.rev.coltfrance.com) has joined #dig
14:49:54 [Sebastien-L]: nice deiu
14:50:46 [Sebastien-L]: hello deiu melvster presbrey
14:50:56 [melvster]: hi :)
14:51:07 [deiu]: hi
14:51:13 [Sebastien-L]: I haven't tested yet but I think there's an issue with the unloading of a graph in rdflib
14:51:15 [Sebastien-L]: this.unload = function(term) {
14:51:15 [Sebastien-L]: this.store.removeMany(undefined, undefined, undefined, term)
14:51:15 [Sebastien-L]: delete this.requested[term.uri]; // So it can be loaded again
14:51:15 [Sebastien-L]: }
14:51:38 [Sebastien-L]: so the graph node is removed but the metadatas associated to it (the request/response blanknode for exemple) are never removed
14:52:33 [deiu]: you are probably right
14:52:36 [Sebastien-L]: it seems that the code to get the request node is to get the subject of this: var requests = kb.each(undefined, ns.link("requestedURI"), doc.uri);
14:53:06 [deiu]: rdflib needs an overhaul
14:53:16 [Sebastien-L]: so if we unload the graph and refetch iit (or refresh it) we may end up having to request nodes being bound to the uri
14:53:36 [deiu]: yeah, I don't like bnodes especially for that reason
14:54:21 [deiu]: connection metadata should be stored in graphs with hash (relative) uris
14:54:43 [Sebastien-L]: not sure to understand
14:55:42 [deiu]: instead of using a bnode for that metadata, you put it in a graph with a hash uri
14:56:42 [Sebastien-L]: like uri#meta ?
14:58:09 [deiu]: something like that
14:58:31 [Sebastien-L]: the matter is that a subject of the graph could already be <#meta>
14:58:52 [Sebastien-L]: i don't really have any problem with the bnodes except it is harder to retrieve
14:58:56 [deiu]: it shouldn't matter, since you should be using the ?why
14:59:03 [Sebastien-L]: that's true
14:59:04 [deiu]: it's a quad store
14:59:14 [Sebastien-L]: but my trouble is not with the bnodes
14:59:21 [Sebastien-L]: it is that if a resource is fetched 2 times
14:59:46 [deiu]: yes, I understand
14:59:55 [Sebastien-L]: the triple (requestNode,Link("requestedURI"),uriLiteral) is added twice
15:00:11 [Sebastien-L]: so we end up requesting the store and getting 2 differnet request nodes
15:00:22 [Sebastien-L]: and the metadatas may have changed between the 2 requests
15:00:41 [deiu]: hmm, to me it looks like removeMany() removes all the triples based on ?why
15:01:38 [Sebastien-L]: yes deiu but the problem is that this triple is bound to the fetcher.appNode , a global blank node
15:01:47 [deiu]: oh
15:01:49 [Sebastien-L]: so you can't cleanup these triples unless you clean the whole fetcher
15:01:56 [deiu]: right
15:02:21 [deiu]: and you don't want to reset the fetcher?
15:02:24 [Sebastien-L]: all the triples related to an uri aren't stored with why = uri
15:02:43 [Sebastien-L]: hmm it's not a current problem I have but just wonder if it may be a problem some day
15:02:51 [Sebastien-L]: we may want to refresh a resource sometime
15:03:08 [deiu]: why not reinitialize the fetcher?
15:03:16 [Sebastien-L]: for exemple automatically refresh all resources that have been fetched more than 10 minuts ago
15:03:18 [deiu]: are you doing longpoll?
15:03:34 [Sebastien-L]: because I don't want to remove all my data
15:03:34 [deiu]: I see, so you use the metadata for that
15:03:52 [Sebastien-L]: no I use metadatas to get the headers http status
15:04:40 [Sebastien-L]: I just wonder how we can cache rdf graphes in the fetcher like we use normal caches, by providing options like LRU, time to live etc
15:04:48 [deiu]: ok wait..so why do you still need to use the same fetcher? why not just redo the request since some metadata can change between requests?
15:05:15 [Sebastien-L]: deiu, I can do the same request by unloading the graph and refetching it
15:05:18 [Sebastien-L]: this is not a problem
15:05:32 [Sebastien-L]: the problem is that then the store will have 2 request nodes for the same URI
15:05:52 [Sebastien-L]: and I won't be able to get the metadata because I'm not sure which bnode to use since there are 2 nodes
15:05:56 [deiu]: not if you reinitialize the fetcher, which shouldn't be a problem
15:06:19 [Sebastien-L]: deiu, reinitializing the fetcher means you clean your whole cache
15:06:41 [Sebastien-L]: I want to unload a single graph, not the many resources I have already fetched which still need to be cached
15:06:56 [deiu]: ok, I see now
15:07:07 [Sebastien-L]: we could for sure reinitialize the fetcher everytime but that seems unefficient
15:07:27 [Sebastien-L]: I think rdflib should cleanup metadatas too and not only the graph
15:07:48 [deiu]: well, I've had some problems with caching in rdflib so I don't rely on it for that purpose
15:07:54 [Sebastien-L]: or at least provide a request timestamp in the store so that we know which request bnode is related to the data currently in the store
15:08:08 [deiu]: it doesn't work well if the server responds with 304s
15:08:43 [Sebastien-L]: ok
15:09:46 [Sebastien-L]: so how do you bypass rdflib caching?
15:10:04 [deiu]: I don't...for now
15:10:21 [deiu]: I've disabled caching on the server until I come up with a solution
15:10:30 [deiu]: it sucks but I need to have the demos working
15:11:50 [Sebastien-L]: yes it's already kind of hard :)
15:22:48 [bblfish]: yep
15:23:00 [bblfish]: But its a good starting point.
15:49:55 [sandro]: deiu, how happy with this are you, vs making some of the changes I suggested? I'm not seeing any feedback from anyone.
15:49:56 [bblfish]: np :-)
16:01:05 [sandro]: bblfish, I'm curious what you thought of the video. Obviously there was no time to get into webid, etc.
16:04:04 [bblfish]: I think you need to find a trick to not have the certificate open up twice in the same window. People can't understand that. You need to open a new browser window on the users site.
16:04:26 [bblfish]: where he will authenticate, and allow the JS access.
16:05:09 [bblfish]: The new browser window should probably be the LDPC of the new space that gets created, where you can also somehow give access to the new JS agent
16:05:24 [bblfish]: s/be/open up on the/
16:06:28 [bblfish]: does that make sense?
16:07:32 [bblfish]: ( I am just thinking off the top of my head, and looked at the video very quickly in a work environment )
16:07:40 [sandro]: I'm not sure exactly what you're saying, but Andrei and I have a plan for getting us down to one pop-up, yes. (or zero popups, for folks who'd prefer to use passwords instead of client certs.)
16:08:18 [sandro]: Aside from the webid 5 seconds, did the rest of the video seem clear enough>
16:08:45 [sandro]: no worries if you didnt really pay attention.
16:13:08 [bblfish]: https://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo
16:13:53 [bblfish]: this is the sequence diagram
16:13:54 [bblfish]: https://blogs.oracle.com/bblfish/resource/2009/print.com.sequence.pdf
16:14:22 [bblfish]: (it's messed up in the blog, cause Oracle changed the sun urls, but did the redirects badly )
16:15:24 [bblfish]: The trick there was to create a simple protocol to allow you to give rights to services on the web that you want to use
16:15:33 [bblfish]: which is what you want to do
16:16:11 [bblfish]: now I had not quite thought through LDP cause it was before LDP
16:16:38 [bblfish]: otherwise the video seemed very interesting. I can look at it further later.
16:18:41 [bblfish]: just thinking through authentication issue https://github.com/linkeddata/rdflib.js/issues/36
16:21:33 [sandro]: sandro has left #dig
16:21:41 [sandro]: sandro (~sandro@ssh.w3.org) has joined #dig
16:36:09 [deiu]: sandro: I'm not sure, I might redo the video
17:04:12 [Sebastien-L]: deiu since you have set the withCredentials = true by default I have troubles with RDFLib
17:04:52 [deiu]: why?
17:05:47 [Sebastien-L]: now when we use a CORS proxy with Access-Control-Allow-Origin: *
17:06:18 [Sebastien-L]: I see many warnings like
17:06:19 [Sebastien-L]: XMLHttpRequest cannot load http://localhost:9000/srv/cors?url=http%3A%2F%2Fhandtwerk.de%2Ffoaf.rdf. Wildcards cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'https://sebastien1.localhost:8443' is therefore not allowed access.
17:07:24 [Sebastien-L]: presbrey, commented here to use a non wildcard origin https://github.com/linkeddata/rdflib.js/pull/35
17:07:43 [Sebastien-L]: but I'm not really sure what else could I use for a CORS proxy
17:28:10 [Sebastien-L]: deiu, what was the problem exactly with credentials : false?
17:29:48 [deiu]: firefox does not send client certs through ajax calls
17:49:23 [Sebastien-L]: ok :(
17:52:15 [deiu]: Sebastien-L: withCredentials won't work if you use wildcards in Allow-Origin
17:56:48 [Sebastien-L]: the problem is that fixing this seems to add addional cors constraints on some other cases :(
18:03:00 [deiu]: you should also set the proper Origin header
18:03:06 [deiu]: s/also/always
18:03:22 [deiu]: otherwise you'll get unexpected results
18:18:14 [bblfish]: I wrote up a mail on the ietf HTTP mailing list with issues about authentication http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1039.html
18:19:07 [bblfish]: it's kind of a tricky one.
18:20:10 [bblfish]: bblfish has quit (Remote host closed the connection)
18:20:37 [bblfish]: bblfish (~bblfish@host.214.33.23.62.rev.coltfrance.com) has joined #dig
18:22:57 [Sebastien-L]: Sebastien-L has quit (Ping timeout: 255 seconds)
18:24:49 [bblfish]: bblfish has quit (Ping timeout: 240 seconds)
18:47:55 [deiu]: deiu has quit (Ping timeout: 264 seconds)
19:01:01 [deiu]: deiu (~andrei@w3cdhcp71.w3.org) has joined #dig
19:01:02 [deiu]: deiu has quit (Changing host)
19:01:02 [deiu]: deiu (~andrei@unaffiliated/deiu) has joined #dig
19:10:45 [bblfish]: bblfish (~bblfish@AAubervilliers-653-1-103-251.w83-199.abo.wanadoo.fr) has joined #dig
19:14:29 [bblfish_]: bblfish_ (~bblfish@AAubervilliers-653-1-103-251.w83-199.abo.wanadoo.fr) has joined #dig
19:18:07 [bblfish]: bblfish has quit (Ping timeout: 264 seconds)
19:19:55 [bblfish_]: bblfish_ has quit (Ping timeout: 264 seconds)
19:21:07 [scor]: scor has quit (Quit: scor)
19:46:22 [scor]: scor (~scor@c-98-217-11-242.hsd1.ma.comcast.net) has joined #dig
19:46:22 [scor]: scor has quit (Changing host)
19:46:22 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
19:47:32 [scor]: scor has quit (Client Quit)
19:49:00 [scor]: scor (~scor@c-98-217-11-242.hsd1.ma.comcast.net) has joined #dig
19:49:00 [scor]: scor has quit (Changing host)
19:49:00 [scor]: scor (~scor@drupal.org/user/52142/view) has joined #dig
19:53:19 [jmvanel]: jmvanel has quit (Ping timeout: 264 seconds)
20:19:39 [RalphS]: RalphS has quit ()
20:50:04 [deiu]: presbrey, sandro: cimba.co now supports search by name/mbox instead of using the WebID
21:04:19 [jmvanel]: jmvanel (~jmvanel@123.0.88.79.rev.sfr.net) has joined #dig
21:07:30 [melvster]: deiu: awesome work! :)
21:07:43 [melvster]: 'Hi Melvin Carvalho! We could not find a shared storage space in your WebID profile.'
21:09:11 [deiu]: melvster: it turns out that's the only relation you need
21:09:31 [deiu]: it should point at your storage space (rww.io/data.fm/etc)
21:09:56 [deiu]: apps will "follow their nose" to find out where to read/write data
21:10:19 [melvster]: deiu: I already use the webid -> preferences -> workspace pattern ...
21:10:35 [melvster]: do i need a new predicate?
21:10:53 [melvster]: → http://www.w3.org/ns/pim/space#preferencesFile → http://melvin.rww.io/preferences
21:11:15 [deiu]: http://www.w3.org/ns/pim/space#storage
21:12:23 [melvster]: hmm I've been using
21:12:25 [melvster]: <http://melvincarvalho.com/#me>
21:12:25 [melvster]: <http://www.w3.org/ns/pim/space#workspace> <workspace/> .
21:12:58 [melvster]: at http://melvin.rww.io/preferences
21:13:07 [melvster]: ok I guess I'll just add storage to my webid then ...
21:14:36 [deiu]: workspace is more of a dedicated space
21:14:41 [deiu]: #storage is more generic
21:14:57 [melvster]: ok got it thanks!
21:15:01 [deiu]: Cimba uses #workspace for the microblog space
21:15:35 [deiu]: pim#space -> pim#workspace -> sioc#Space
21:16:07 [melvster]: let me do that
21:18:42 [melvster]: done!
21:18:45 [melvster]: i have a microblog! :)
21:19:16 [deiu]: awesome :)
21:19:25 [deiu]: now go to Channels and Find
21:20:39 [melvster]: woo hoo you have 4 channels :)
21:21:24 [deiu]: :)
21:21:45 [melvster]: deiu: how does it do the search?
21:22:10 [deiu]: we've set up a service that indexes WebIDs
21:22:18 [deiu]: try http://webizen.org/v1/search?q=melvin
21:22:18 [melvster]: superb
21:22:24 [deiu]: it's a public service
21:22:27 [melvster]: great!
21:22:30 [deiu]: anyone can use it to find people
21:22:44 [melvster]: this is awesome
21:23:05 [deiu]: simply do an ajax call to that endpoint
21:23:22 [deiu]: bye bye pasting long WebIDs :)
21:24:06 [melvster]: hehe
21:24:28 [deiu]: results should be curated a bit though, but given that this server has been available for 2 days...take it with a grain of salt :)
21:24:31 [melvster]: this is amazing
21:25:02 [deiu]: I'll add a nice landing page for webizen.org next
21:25:08 [deiu]: so you can use it like a search engine
21:26:19 [deiu]: btw, http://social-webarch.github.io/cimba/
21:26:35 [melvster]: thanks!
21:26:37 [deiu]: the gh-page serve the "dark" Cimba
21:26:42 [deiu]: gh-pages*
21:27:11 [deiu]: feel free to fork it and add new features :)
21:27:32 [deiu]: github repo: https://github.com/social-webarch/cimba
21:28:11 [melvster]: great thanks
21:31:04 [melvster]: i love it
21:33:32 [deiu]: I like the dark theme better
21:35:13 [bblfish]: bblfish (~bblfish@AAubervilliers-651-1-124-48.w86-198.abo.wanadoo.fr) has joined #dig
21:35:37 [melvster]: both are impressive :)
22:35:30 [sandro]: just finished the poster. going to bed. back in ~7 hours.
22:47:46 [deiu]: deiu has quit (Ping timeout: 246 seconds)
22:54:52 [melvster]: melvster has quit (Remote host closed the connection)
22:55:07 [jmvanel]: jmvanel has quit (Ping timeout: 246 seconds)
22:59:16 [melvster]: melvster (~melvster@89.176.108.70) has joined #dig
23:16:39 [scor]: scor has quit (Quit: scor)