ResponseDB Development Log

@2:24 - I have just got the callbacks round tripping, but need still to hook it back to the sR such that the video items show up.  Then I need to do the same thing for each type of object (comments, users) etc.  The Morsel model should help.open

----

Ok so the dbgetvideo call returns a built video, so I have to do this in the case of the background message and need to study dbgetvideo so see how best to do this, and if I want to modify dbgetvideo as part of the change.

@10:45pm listening to The Hobbit and watching it out of the corner of my eye as I iterate over this.  Really it should have been designed ahead of time but this will get a decent solution quicker.  I have the round trip working, but I now need to have background.js call the spider function it was asked to call in the case of curse (it'll do the save).  I intend to write a spider.handle_background_event and spider.handle_background_callback for either side of the exchange.  Must refresh my memory as to how far I got on this with the save_video call (which was easier because it was one directional).

@12:08 Wrapping up for the night. Tomorrow I will need to create those functions and write a wiki, perhaps, about the various functions of interest, such as executeAlternateMode and so on.

Got a teeth cleaning today... my hygienist seems immune to human suffering, which I guess is a strength for her in her professions.  She's a nice enough person, she just doesn't seem to comprehend the obvious suffering of others and has no notion as to which of her  techniques is the least entirely unenjoyable. NOTE TO SELF: by sonic toothbrush and see if cleanings are not as difficult.  Also, move to maine and change doctors... we are trapped with whatever doctors the plantation hires here on the islands.

I've already been looking at the code but stayed up till 4:30am working on the code and playing sauerbraten so I didn't start till 12:30 today.  Right now I'm passing the callback dictionary back and forth that relates function names to ids in a particular send/listen exchange.  It's sent with the message so the client end gets to set the callback name with the id so that when it is returned the (spider and novem on behalf of the) client can find the actual function which has been stored by an id assigned in add_callback.

This dictionary is created in novem.send(..) which looks for functions in the "options" argument and indexes them.

4:13pm Wait a minute, it is indexed by the name in this case, only in the register is it indexed by ID, as appropriate.  But now I'll have to work through it to make sure it's in place... just cause that's how my mind works... just in case, b/c why am I confused about it?  answer me that! rhetorically speaking that is.

7:54pm listening to "What the Ancients Knew: The Chinese"  Pretty good stuff.

devlog: remembered/noticed

I either turned off the content script monitoring, or broke it, or it stopped working for some other reason, and that will have to be looked into next after the novem redirection stuff worked.  Started the ThreadingStructures page at github.

MCWCAM : Thot 7.0

The mad coder what codes at midnight sat in the starboard logistics bay, watching log files and monitoring the culture.  In the background maggot brain played softly.  Before him lay a coding problem.  Three processes, all running the Thot reasoning system, having the first conversation in the first version, Thot 7.0.

@6:59 putzing around with my monoprice tablet, installed pencil, which is awesome but had a bug (installing qt supposed to help?)... can't get pressure sensitivity to work in gimp but am probably doing something wrong as it seems to know about the  pen.

Onto some serious code which I've also putzed with... decided yesterday to take a couple weeks vacation, woot woot.

(don't like ch ristmas... bah humbug!)

Did I link this page yet? Threading Diagrams

I have the callback message going back correctly (callback fires in background.js then generates a message) but I'm not dispatching it on the content script side atm.  I want to solve that, get the DB back to the old performance and implement a summary page, then a subscription system.

@10:45 making slow progress... I need to set in mind the whole exchange... one issue, I have send go through the options looking for functions, making a function table, assigning ids.  All quite clear, but then debugging when the callback is generated it does a send and the structure has both the new callback table (for background.js calling send) and the table originally sent from the client.  I was calling this _sender_callback_dict and that was confusing.  Now it's _client_callback_dict and it's mort clear, because of the nesting level, which was the client (i.e. the _client_callback_dict in the event structure is the client of the event, one step above, it's the message client (which is the current sender).

It will be nice when it's done.

Then i want to do a subscribe feature and a summary page.

inter process/tab/page callbacks

@8:31pm:

• _njn.send has to add_callback, and then I need to send information about the callback to background so that an id can be sent back and the caller can know when an asynchronous message is really a callback. It's a real callback, but it's also simulated in the sense that generally I let the iDB trigger these callbacks.  I think.  This stuff will need some going over.

By the way, the github has not been made public... and still won't have been since no one is reading this blog, so this is a pre-announcement of the github repository.  The tool I'm talking about is responseDB, which is the seed of my structured conversation theory applied to youtube in the form of a chrome (for now) extension that modifies youtube video pages and scans youtube from the user's browser, thus able to implement quite good subscription and reply (annotation) features under the control of the user.  I'm going to release it open source (thus the github).

@8:58pm got a text from my daughter was texting her back... I'm going to look at send and have it send the callback id info. I also think I will have to write a "callback_summary()" function to build the structure that will be attached to the message.

My system drive in my mac mini crashed again and so I need a new computer.  I shopped around, I think I'll get a zareason machine with Ubuntu.  I was thinking about system76 too but zareason supports more kinds of OS and I take that as an evidence that their machines are more widely compatible and they're not just supplying their own drivers that won't exist in an ubuntu update!

maybe not.

So I was right at the edge of finding out why my callback system wasn't working.  The short version (I was keeping notes in wiki pages, you'll never read them, at github... ok, short version: I had been saving  information happilly in the IndexedDB (iDB from now on) from the content script which saved it in the domain based namespace of the site the content script was working with.  This data was not available to background no other pages (e.g. extension pages I might launch, such as summaries or extra features beyond what the content script (or popup or settings) offers).

The content script was using the novem _njn object to do this so I have altered _njn to be able to send a message to another "process" (which is how each of these "pages" acts within the context of the extension), to store and retrieve objects from the iDB.  This way the background.js process  (it's the logical choice though anything could do it... problem being nothing else is always around) can store and retrieve data from  the iDB transparently to the code in the content script or anyone using the _njn in some mode the name of which I've already forgotten.  "Send_to_background" I think.

Anyway doing a call is simple, so the saves went rapidly, but handling callbacks, which are asynchronous are more difficult.  They shouldn't be too difficult, I found out my problem was that there is a .sendMessage in chrome.runtime and in chrome.tabs and I had to use the latter to send messages back to the tab (of course, I just hadn't noticed the two versions).  Also difficult is all the deferred action.  Now I have to deal with simulating the return even from _njn running in the content script, loading the object correctly and whatnot.  It's not at all normalized and generalized, my goal is just to get a working system that allows everything to work as it had before and also make a simple summary page.

Maybe the system will work better letting the background do the relatively slow iDB queries, but I don't know that.

Another thing is it's just kind of confusing refactoring like this, with messages between processes.