12:36:14 <DIGlogger> DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
12:36:14 <jordan.freenode.net> topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
12:36:14 <jordan.freenode.net> Users on #dig: DIGlogger RalphS melvster IvanHerman mhausenblas timbl presbrey jambo webr3 danbri nunnun amy sandro mattl IPaparrizos ericP gbot30
12:38:34 <junaidnaseer> junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
12:41:23 <junaidnaseer> junaidnaseer has quit (Client Quit)
12:57:10 <kennyluck> kennyluck (~kennyluck@2001:200:1c0:3602:225:ff:fe4d:f8c7) has joined #dig
13:39:20 <junaidnaseer> junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
13:53:00 <kennyluck> but tabulator doesn't try to build panes on top of W3C widgets. lol
14:03:08 <nunnun> nunnun is now known as nunnun_away
14:06:58 <nunnun_away> nunnun_away is now known as nunnun
14:18:57 <webr3> kennyluck, nothing really tries to build on top of w3c widgets afaik, I've been nudging and pushing Marcos et al to try and get widget support in to the main browser context, and so that all extensions are deployed using web tech stack, just packaged/signed and cached
14:19:28 <webr3> some are v positive about it, but some of the browsers are not so keen on loosing their niche extension markets
14:23:02 <oshani> oshani (~oshani@124.43.46.240) has joined #dig
14:52:43 <marisol> marisol (~marisol@pool-151-203-91-62.bos.east.verizon.net) has joined #dig
15:36:49 <oshani> oshani has quit (Quit: Mama nidi!)
15:39:31 <oshani> oshani (~oshani@124.43.46.240) has joined #dig
16:02:17 <betehess> betehess (~betehess@31-35-254.wireless.csail.mit.edu) has joined #dig
16:09:23 <nunnun> nunnun has left #dig
16:09:44 <nunnun> nunnun (~nunnun@irc.v6.nunnun.jp) has joined #dig
16:11:00 <IvanHerman> IvanHerman has quit (Quit: bye guys)
16:31:38 <oshani_> oshani_ (~oshani@124.43.42.170) has joined #dig
16:34:04 <oshani> oshani has quit (Ping timeout: 260 seconds)
16:34:05 <oshani_> oshani_ is now known as oshani
16:39:49 <oshani> oshani has quit (Quit: Mama nidi!)
16:51:53 <oshani> oshani (~oshani@124.43.42.170) has joined #dig
17:53:30 <oshani> oshani has quit (Quit: Mama nidi!)
17:56:55 <oshani> oshani (~oshani@124.43.42.170) has joined #dig
18:05:55 <mhausenblas> mhausenblas has quit (Quit: mhausenblas)
18:07:50 <marisol> marisol is now known as mari-brb
18:08:42 <timbl> I have wonderde about tha
18:08:42 <timbl> tabulatro not using widget packaging
18:26:28 <timbl> timbl has quit (Read error: Connection reset by peer)
19:06:45 <timbl> timbl (~timbl@pool-96-237-236-230.bstnma.fios.verizon.net) has joined #dig
19:18:11 <oshani> oshani has quit (Quit: Mama nidi!)
19:46:37 <mari-brb> mari-brb is now known as mari-mami
20:14:09 <timbl_> timbl_ (~timbl@pool-96-237-236-230.bstnma.fios.verizon.net) has joined #dig
20:17:58 <timbl> timbl has quit (Ping timeout: 246 seconds)
20:17:58 <timbl_> timbl_ is now known as timbl
20:28:23 <melvster> melvster has quit (Remote host closed the connection)
20:28:42 <melvster> melvster (~melvster@p579F958C.dip.t-dialin.net) has joined #dig
20:43:51 <junaidnaseer> junaidnaseer has quit (Quit: Leaving.)
20:56:51 <junaidnaseer> junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
21:03:20 <junaidnaseer> junaidnaseer has quit (Quit: Leaving.)
21:20:30 <RalphS> RalphS has quit (Quit: outah here ...)
21:21:43 <presbrey> I think tabulator will be implemented in chromium a lot more easily if it used local storage objects
21:25:49 <presbrey> chrome uses process separation for tabs and extensions and requires sendMessage and onMessage API between each context
21:29:37 <junaidnaseer> junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
21:31:39 <timbl> timbl has quit (Remote host closed the connection)
21:31:47 <timbl> timbl (~timbl@pool-96-237-236-230.bstnma.fios.verizon.net) has joined #dig
21:32:34 <timbl> So it can't share a rdf store?
21:32:44 <junaidnaseer> junaidnaseer has quit (Client Quit)
21:33:04 <timbl> process separation for tabs
21:33:29 <timbl> Bu the tabulator experience is kinda predicated on accumukating more and more data in the whole session.
21:33:49 <timbl> I suupose an alternative is to put the tabulator store in a sep process running HTTP 
21:38:21 <mari-mami> mari-mami has quit (Quit: mari-mami)
21:40:12 <presbrey> I'm not even sure content tabs can access the extension's local storage
21:40:22 <presbrey> its quite secure!
21:40:46 <presbrey> s/its/looks/
21:43:17 <presbrey> been playing with it a bit today
21:43:23 <presbrey> http://code.google.com/chrome/extensions/content_scripts.html#pi -- programmatic injection
21:44:05 <presbrey> they are advertising sending script around as strings
21:44:21 <presbrey> so no shared DOM access across all extension instances
21:46:10 <presbrey> http://code.google.com/chrome/extensions/content_scripts.html#host-page-communication -- host page communication
21:46:28 <presbrey> looks like quite a bit of hacking is needed
21:47:12 <presbrey> I committed a chrome extension shim
21:47:19 <presbrey> thought it might be an easy wrapping job
21:47:36 <presbrey> but *sigh*
21:50:06 <webr3> can it leverage workers?
21:50:26 <webr3> each webworker can be shared, so it's a central process that can be used by several tabs, ideal for dbs/storage
21:51:06 <webr3> workers etc have no access to dom though, thus no access to rdf/xml or rdfa..
22:00:20 <jambo> presbrey: does a chrome extension not have a single background page even though it's running in many tabs?
22:01:57 <jambo> i would think that you could keep the store in the background page and have a write a version of the store that actually just forwards messages off to the background page
22:03:09 <jambo> you're right though that it would not simply be a wrapper in that case
22:16:41 <presbrey> jambo: it does have a single background page
22:17:03 <presbrey> but that single page is in a separate process from all others (tabs, extensions, etc)
22:17:10 <jambo> sure
22:17:28 <presbrey> one quickie for you
22:17:48 <jambo> it would work though if you just used a different sort of store, right?
22:17:50 <presbrey> I notice lots of the libraries start by getting a reference to tabulator,  var tabulator = Components...
22:18:04 <presbrey> where is that component first defined, xpcom.js?
22:18:52 <jambo> yeah, its where wrappedJSObject gets set.
22:19:11 <jambo> looking at hg, its line 32
22:20:12 <presbrey> next step I think is to backtrack from Chrome to Firefox 4 support
22:20:14 <jambo> remember that if you try to hang values created in a browser context off of that JS object, when that browser window closes, those values will get cleaned up and disappear
22:21:03 <presbrey> not trying to do anything new, loading in FF4, one of the var tabulator=Components[]... is the first to fail
22:21:13 <jambo> hrm
22:21:20 <jambo> where is it
22:21:35 <presbrey> DIGlogger, pointer?
22:21:35 <presbrey> See http://dig.csail.mit.edu/irc/dig/2011-01-06#T22-21-35
22:22:49 <jambo> maybe something changed in ff4 so that the xpcom component cannot register?
22:23:39 <presbrey> that seems likely
22:23:57 <jambo> i would assume that getting null out of Cc.foo means the component didn't register
22:24:13 <jambo> are you just flat out plugging the code in?
22:24:37 <presbrey> mostly
22:24:46 <jambo> okay
22:24:49 <presbrey> I updated install.rdf and chrome.manifest a bit I think
22:24:57 <jambo> I couldn't find the reference in the log, do you know which file it is
22:25:03 <presbrey> yeah I'm looking
22:25:11 <jambo> OK
22:25:16 <presbrey> I have to reproduce it as diglogger doesn't have our pastes from yesterday
22:25:20 <jambo> ah
22:25:32 <jambo> alright, I have to go for a bit, but I'll be checking back
22:48:03 <presbrey> browserInit.js line 2 and statuswidget.js line 3
22:48:13 <presbrey> so yes I think the xpcom registration is failing
22:48:20 <jambo> okay.
22:48:36 <presbrey> https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0
22:48:44 <jambo> iw as just about to post that exact link
22:49:02 <presbrey> haha
22:49:33 <presbrey> how does the xpcom component work with the overlay? why are both needed?
22:49:33 <jambo> looks pretty simple
22:50:36 <jambo> stuff like icons appearing in the location bar, items that appear in the menu bar, etc, have to be loaded through the overlay of the browser.
22:50:54 <jambo> there used to be more in the overlay, but that _should_ be all gone now.
22:51:27 <jambo> i think oshani had put a lot of code for the policy stuff
22:51:30 <jambo> directly in the overlay
22:52:02 <presbrey> I see multiple implementations of the <div id="outline"> body replacement
22:52:12 <presbrey> are there multiple paths for setting up the replacement document?
22:53:10 <jambo> if its in xpcom components, i think that may have been copied to create an n3 converter rather than with inheritance for dubious reasons
22:53:33 <jambo> otherwise, i'm going to guess it might be related to the items in the location bar, which you would have to talk to kennyluck about
22:54:05 <jambo> it's been a while, though.  I did think that I had cleaned all of that up in my changes, but I could be wrong :(
22:54:23 <presbrey> cool thanks
22:54:49 <presbrey> earlier I was trying to understand which setup paths would be important for a chrome extension
22:55:08 <presbrey> where the component registration might be abstracted away
22:55:47 <presbrey> and which part setup the outline interface
22:56:18 <presbrey> thinking it would be easy to tweak the addons once the outline was in place
22:56:22 <jambo> the biggest pain is that there isnt a very nice abstraction barrier between the outline code and the store
22:56:33 <presbrey> and kb
22:57:02 <jambo> they flow together a bit too much to just say, "well, create a kb over here, and create an outline over here, and just wire them together" unfortunately
22:57:19 <jambo> that's still hanging around from when it was assumed that everything would just be running in a single page anyway
23:00:07 <webr3> tomayac may be good to talk to, he's def made google extensions working w/ rdf(a)
23:00:45 <presbrey> cool w/ shared storage and cross-site xhr?
23:01:12 <webr3> unsure about shared storage, def w/ cross site xhr
23:01:47 <webr3> see: http://blog.tomayac.de/
23:02:06 <webr3> even the source of his extensions may be good to look at as reference
23:04:40 <webr3> DIGlogger, pointer?
23:04:40 <webr3> See http://dig.csail.mit.edu/irc/dig/2011-01-06#T23-04-40