Welcome Jon!

Feb 24, 2014 at 7:52 PM
So I am super happy to say that Thali has increased and now Jon Udell has joined! Jon will be focused on the experience for folks writing Thali apps while I focused on the low level plumbing.
Feb 25, 2014 at 1:07 PM
Edited Feb 25, 2014 at 6:09 PM
Thanks Yaron. I've been interested in Thali-like systems for a long time (http://jonudell.net/bytecols/2000-08-30.html), Here's hoping this one has legs.
Feb 25, 2014 at 6:16 PM
So, here's a little teaser: http://www.youtube.com/watch?v=o_gUdMKkvu8. It's Dave Winer's LittleOutliner running on CouchDB, syncing P2P between Firefox and IE on one machine and Chrome on another. This is not yet a Thali app, just a port of LittleOutliner to the CouchApp (http://couchapp.org/page/index) model. We (mostly you) have more work to do before this will work in Thali. But the vanilla CouchApp is already interesting, and when we can bring Thali's identity and security capabilities to the table it will become much more interesting.
Feb 26, 2014 at 4:22 AM
tldr - Actually you could Thalize LittleOutliner today. The pieces really do exist.

O.k., first, that is cool. It's all theory until you see the bits fly!

How to set up LittleOutliner in Thali Land

But let's talk about the ideal set up here.

Chrome using PouchDB who is talking to Thali over the native host. PouchDB would be a client of the Thali Device Hub. All of this is doable (modulo a few minor bugs I need to fix) right now.

Computer A would have the user typing.
Computer B would have the user receiving the updates.
(Yes, everything will work bi-directionally but I'm going to talk about a single direction to make the set up easier to understand)

So on Computer A pouchDB would set up a push replication from Computer A's Thali Device Hub (TDH) to Computer B's TDH. This would be set up by using PouchDB to issue a continuous push replication request to the machine's TDH. That all works today other than the push replication bug I introduced that I'm in the middle of fixing.

Getting notifications of changes on computer B

The main problem on Computer B is - how does it know when its TDH has been updated by Computer A's TDH? In the short term the answer is that we should set up a continuous replication between PouchDB on Computer B and it's local Thali Device Hub. In other words we will suck changes from computer B's TDH into the browser. We would then hook the change logic so we would get automatically notified anytime an update comes in and then we would delete the record in the browser since we don't need it after we have been notified about it. To be honest I'm not 100% sure PouchDB will handle this scenario. Since you have PouchDB hooked up to couch could you try to set up a continuous replication from Couch to your PouchDB and see what happens? I looked through the PouchDB source code but I didn't see a timer jumping out at me so I'm not sure if a continuous pull replication will actually work. I also know that there is an outstanding bug in PouchdB's support for replicating attachments (see https://github.com/daleharvey/pouchdb/issues/1007) but this mechanism should be used for message updates (e.g. JSON) and not for the core attachments. So I think we should be fine.

Note that if PouchDB doesn't support continuous pull replications (read: polling) then it's easy enough to set up our own polling by just setting up a timer to initiate a one time pull replication and see if anything new shows up.

So one way or another this IS doable, right now, without any serious voodoo.

In the longer term I really want to set up a server that PouchDB can listen to so we can switch from pull to push (I even have a bunch of the code needed to make this work) but honestly I don't think that polling a local server is all that bad and I'd like to keep things simple for now.

So, my point is, everything you need to 'thalizie' your Demo actually exists, right now (modulo me fixing the push replication bug which will happen once I stop writing email and get back to code =).

Making it peer to peer

The only gotcha I see is how to set up the peer to peer connection itself. The problem is the Android VM. It won't accept incoming connections from off machine and I've tried to use net bridges, relays, etc. to fool it without success. However there is explicitly some voodoo to let you configure two Android VMs on the same box and set up a local network between them. I've never actually tried it though. You would then assign each VM's TDH a different port (e.g. 9898 and 9899) and Computer 'A' (just a Chrome instance) would use 9898 and Computer 'B' (another Chrome instance) would use 9899 and you are in business.

Another alternative is to use two different computers but then you need to use an Android Device on computer B so it can be pushed changes from computer A. Once I add in Tor support (next on my todo list after fixing push replication) that problem goes away and you can just use two VMs on two machines.

Of course once the CouchBase Lite folks get the Java support up and running for CouchBase Lite then this all gets much simpler since the connection limitations of the Android VM wouldn't apply at all in that case.


But, long story short - you really and truly can Thalize LittleOutliner today!
Feb 27, 2014 at 1:21 PM
Yes I think that's true. From the POV of a CouchApp developer, though, you'd like to just switch from this:

to this:

And then you'd like to have stuff mentioned in LittleOutliner.html, like:

<script src="/_utils/script/jquery.js"></script>
<script src="/_utils/script/jquery.couch.js"></script>
<script src="bootstrap.min.js"></script>
<script src="strings.js"></script>
<script src="utils.js"></script>
<script src="concord2.js"></script>

...also come along for the ride. We've discussed a custom scheme handler for the browser but a) that's a fireswamp full of ROUSs, and b) I don't think it addresses things like src="/_utils/script/jquery.couch.js".

So I'm going to try proxying localhost through something that uses the machinery in http://thali.codeplex.com/SourceControl/latest#Production/Utilities/DotNetUtilities/DotNetUtilities/ChromeExtension/. Currently that provides an XMLHttpRequest replacement that enables AJAX calls to use Thali-style URLs. Using it, I can fetch LittleOutliner.html from Thali, and it's conceivable I could rewrite that page with code that uses the same method to include the referenced scripts, then document.wite() the whole thing. But yikes. So let me see what mileage we can get out of a full-on proxy.
Feb 27, 2014 at 4:54 PM
I have been thinking about this and there are two ways to tackle it. Either via a webview or via the browser.

I suspect we should try the webview approach first. The reason for this is that WebViews take a bunch of complicated issues (e.g. https://thali.codeplex.com/workitem/25) off our plate in the short term.

In the case of Android I believe the shouldInterceptRequest function would let us 'hook' any URL requests (including, I think, script src calls) and put in our own response.

In the case of the JavaFX WebView I believe you can use the URL.setURLStreamHandlerFactory mechanism to register new kinds of URLs and the webview will honor that and call us.

We should also be able to handle relative URLs in a webview. Either the engine should resolve the relative URL for us (the rules are the same regardless of URL type) or at worst we can resolve it ourselves outside the webview since we can always get to the location and calculate for ourselves the fully qualified value.

I have found that doing things in WebViews is, unfortunately, always an adventure. So I can't promise that everything above will work as advertised. This is at least partially a research project.

Now the obvious problem is - how the heck do you debug?

My guess is that you write the couch app in Chrome with it's lovely debugging using normal couchbase and then when you think it works you move it to Thali and use the webview of your choice to play around with it.


Feb 27, 2014 at 11:48 PM
Sounds good to me. I'll be happy to focus on exploring the wealth of capabilities available to a CouchApp developer. And in particular, what kinds of existing web apps can port to that model with little effort and much gain. Also, after a brief re-immersion in the world of SSL proxies, I'm remembering why I don't go there if I can help it.
Feb 28, 2014 at 9:07 PM
Sorry for taking this long but I updated the splash page on codeplex and on our wiki to include you as our newest contributor!