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)