'Firebase' data sync PaaS

[Turadg Aleahmad]

Firebase could accelerate a bunch of Educoder project development. If only to prototype before scaling as open source. 

'Firebase' Does for Apps What Dropbox Did for Docs | Wired Enterprise | Wired.com
http://m.wired.com/wiredenterprise/2012/04/firebase/

Firebase doesn’t just move information from one client to another. It shuttles all client communications to a central data repository in the proverbial cloud. If multiple people are text chatting, for instance, Firebase doesn’t just send text between the clients. It sends all text to a repository that all clients tap into. When one client updates the repository, the changes are synchronized across all other clients. “The software developer just makes sure the clients are referencing the same piece of data, and all the data transport happens automatically,” Lee says.

Turadg Aleahmad
PhD candidate, HCII

[Matt Zukowski]

Cool... we're actually moving away from sending data via messaging and instead relying more on a combo of shared databases + notifications about updates/changes (so client stores stuff to a REST repo -- monodb generally -- and sends out a notification over XMPP notifying other clients that it has deposited new/updated data). This could fit well into that model, taking care of all the REST request-response stuff.

I suspect thought that there will be a fair bit of resistance at our lab to adopting a proprietary, closed-source technology as a core component (namely from me and Armin :) Buying into this stuff always kind of feels like a deal with the devil... 

Second, this being a "cloud hosted" system, we might have a hard time getting this past ethics. I think we ran into this in the past when our stuff was hosted on Amazon EC2. Is that right Armin? We also sometimes deal with situations where we don't have full cloud/internet access, as for example in the "roadshow" app we're building right now for our trip to Australia.

--
You received this message because you are subscribed to the Google Groups "Educoder" group.
To post to this group, send email to educ...@googlegroups.com.
To unsubscribe from this group, send email to educoder+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/educoder?hl=en.

[R Benjamin Shapiro]

Hey Matt,

We are heading toward a similar model here: using a notification system (via xmpp or something else) to tickle apps into rechecking the status of resources through a RESTful api. How's that been going for you?

Ben

[Armin Krauss]

Yeah I am not a proprietary fan (who know what Facebook buys next ;)

Regarding ethics, Canadian laws and regulation require that research data basically stays in Canada. This is why we have servers run by our department. So it has to run on these machines. The Amazon instance is used for development but never for runs.

Armin

[Matt Zukowski]

Ben, we've already got the notifications-via-XMPP thing going, since that's the core of our Sail platform. The only change for us in adopting this new model is that rather than packaging a lot of data into event payloads, we're keeping all the data it in the repo and forcing clients to go fetch it themselves whenever they need it. So for example in the past if a student made a journal entry, we'd send out a "new_journal_entry' event and package the content in the event's payload. Nowadays we're broadcasting out the same 'new_journal_entry' event, but with only a minimal payload (just the student's user id, for example). When an interested client/agent notices that event, it will go out and fetch the updated content.

The obvious downside is that we've split up a single message into a more complicated message-request-response combo, but in practice this should actually simplify the architecture a bit. A major problem in the past was keeping clients in sync with the current system state -- for example if a student joins a smartroom run half way through, or if a client drops out and comes back in. Previously we were sending some state updates via events/messages ("here's some new content that somebody just generated") and others via request-response ("i just joined, give me all of the content that's been generated so far"). With the new model, you're getting all of your state updates one way (REST), in the same format (packaged as data in a repository rather than message payload). The events/messages only notify you that something has changed.

We're just starting work on two big apps based on this new model. I'll let you know how it goes :)

The Firebase stuff, by the way, is cool because it (in theory) takes care of all of the state update stuff for us. Every client has complete state (a complete copy of the repo, from what I understand), so we can just assume that everyone knows about the current system state, and we can focus on coding just for the activity.

[R Benjamin Shapiro]

Thanks, Matt. It was Sail that inspired us to look into XMPP as a platform for doing notifications :-). We're basically thinking the same thing then, of just sending an id out and then having the client hit that over REST. I think the simplicity this will bring, including only having to have one set of code for querying/storing application data will totally outweigh the downsides of a bit more overhead.

What are the apps you're working on?

Ben

[Matt Zukowski]

Any reasons why you didn't just go with PubSub instead? (We have some good reasons on our end, but wondering what it might have been on yours)

We're getting started on a smartroom run for teaching high school kids to make cross-domain/category connections between concepts in physics (Mike Tissenbaum is designing this), and a multi-user smartboard discussion tool that will hopefully get demoed at ICSL in Australia this July.

[R Benjamin Shapiro]

We haven't committed to a specific framework (XMPP or otherwise) for notifications. Whatever we choose, it'd be good if it had existing support for working with Unity3D.