PeerPouch
PeerPouch copied to clipboard
natevw
Three projects in one! :)
What I mean is that the project encompasses:
- a project that does "discovery over CouchDB" (
share-*) - a project that does "signalling over CouchDB" (
p-signal-*) - a project that does "PouchDB over DataChannel"
and it could be useful to see those as separate entities. (For example it'd definitely be nice to be able to use the "PouchDB over DataChannel" piece to experiment with different discovery / signalling pieces.)
Right now discovery and signalling are definitely mixed together (in SharePouch).
The "PouchDB over DataChannel" piece is kinda in PeerPouch but not fully.
One thing I noticed is that rpc (rpc.bootstrap(..) etc.) is in SharePouch but never used there, maybe those three lines could move to the beginning of PeerPouch right after the handler is identified? (In which case _wrappedAPI wouldn't have to be exposed outside of PeerPouch either since that's the only place it's used.)
Maybe I'm just overthinking this, trying to wrap my head around the various components. :)
For example here's a start at trying to make PeerPouch into a browserifiable set of modules, changing the APIs a little bit to make the modules be more self-contained: https://github.com/shimaore/pouchdb-calendar/commit/14c349e78e5615d1115c62b5f2b8ef3329bfac82
Fun! I'm not sure how useful each component would be in isolation (e.g. CouchDB isn't exactly a great way to signal unless the only tool you allow yourself is PouchDB) and I want to avoid forcing users to have any particular build system — BUT there's certainly room for making the code a bit more modular.
Your summary is fairly accurate. Thanks for writing that out. The one correction I'd make is that there is a separation between the RPC in SharePouch vs. PeerPouch. There is a piece around PeerPouch._shareInitializersByName that is sort of a hack that crosses the concerns in kind of a hacky way between the two, but the rpc.bootstrap is pretty core: PeerPouch is the "client" I guess you could say while SharePouch is more of the "server". So the rpc.bootstrap there is quite critical, as it is what the server uses to actually expose its interface to the client.
Anyway, if you think PeerPouch would be more useful split up that's encouraging and I'd love to support it. My main thing is I want to keep it simple/easy for casual users, so if it ends up getting split across separate files internally I'd want to still provide a pre-built script that can be dropped in.
My main thing is I want to keep it simple/easy for casual users
No worries, I'm only toying with ideas and some code at this point, not my intent to force anyone on any path.
I'm trying to get to a point where I can initiate mobile-to-mobile browser-to-browser PeerPouch sync using (for example) QR codes -- i.e. the mobile browser "initiating" the connection displays SDP as QR code (inside the browser), while the mobile "receiving" scans the QR code, paste its text in browser application, and sync is initiated. Once I get that basic stuff working, iterate and refine the idea.
Thank you for the details about rpc, I'll review those tomorrow, it's getting quite late here!
(Ooops, wrong button.) Sounds like a very fun reason to try separating out the signalling stuff! You'll likely want to gather ICE candidates for a bit before generating the QR code, BTW.
HI @shimaore — I've got another developer interested in using just one of these "projects". Is your split-out version working and do you mind if I pull back your files here?
My plan is to split out at least the PeerConnectionHandler and RPCHandler into ± separate projects (at least separate package.json) and try adding a browserify build step so that there's still a single file folks can drop in for "PeerPouch" but improve the separation/reusability for other things.
Is your split-out version working
I have no idea, I never got to actually testing my changes.
and do you mind if I pull back your files here?
None at all, it is your code with a few copy & paste, really!
This still really needs to happen, I got broadsided with a ton of last-minute client work early this month (can't really complain too much I guess) and all my open source stuff (/other client work) got pretty much completely off the radar.
Could you share more about your use case? For me, splitting it up is mostly so I and others can use the pieces elsewhere and I don't know how much it will immediately benefit PeerPouch itself.
Other usecase could be when you are using pouchdb inside a mobile app through Cordova/Phonegap, you could use this for signaling/discovery: http://developer.android.com/training/connect-devices-wirelessly/nsd.html
That'd be an interesting experiment — IIRC, at one point I was sending a pre-built offer to the "hub" database like you might do with an mDNS TXT record like Bonjour/NSD use. I'm not sure if multiple parties can reply to the same offer though, but worth a try!
On Tue, Feb 17, 2015 at 1:50 PM, Nathan Vander Wilt < [email protected]> wrote:
That'd be an interesting experiment — IIRC, at one point I was sending a pre-built offer to the "hub" database like you might do with an mDNS TXT record like Bonjour/NSD use. I'm not sure if multiple parties can reply to the same offer though, but worth a try!
That's the idea in mDNS!
— Reply to this email directly or view it on GitHub https://github.com/natevw/PeerPouch/issues/6#issuecomment-74702222.
Ing. Nicolás Pace
This is a bit lower than fermata and node-nrf on my list especially since I'm not working on a project that uses this at the moment. (Though I have at least one little idea…) So while I'd like to get back to it (and have had a bit more time for catching up on open source projects lately) I don't want to make any timeline promises since time tends to fly with these things.
The code is somewhat isolated internally, so the main work would be refactoring that and then splitting at least into separate files (if not separate modules and even repos). I think https://github.com/quartzjer/webrtc-peer has some of the more generic "WebRTC wrapper" code split out, so that might be useful at least in the [potentially long] interim.