gabidobocan

Thanks!

Yes you can (and should) also intercept at kernel level, but the kernel can't tell which of your app's dependencies is responsible for the call, only the application knows that.

Racer is great at synchronizing objects, and more flexible than Derby. One key difference between Racer and Telepat is that the Racer client needs to run within a JS container, while Telepat offloads native functionality to native clients. I'd say we're more mobile and user-access oriented than Racer, basically, but we're more architecturally apart as well.

Not yet - unless you do it client-side. We're working on having a proper implementation for this use case.

Collaborating on different properties of a single object is no problem; for working on the same property we don't do diff/merge yet, it's just FIFO.

Thanks! Offline support is on the roadmap - the iOS and Android clients actually already use a local database, so we're nearly there.

Good question, we get this asked a lot (usually in relation with companies such as PubNub or Pusher.io). It's different in a number of ways: - it's compatible with any number of protocols (we call them transports). Currently, we support websockets, APNS and GCM. MQTT could easily be added as a transport protocol for subscribing to channels - it also handles data aggregation (for example if you have a large number of updates on an object in a short amount of time, the system will aggregate them and send only the relevant updates to the subscriber) - it's more open (in my opinion) as it's designed to enable developers to swap out one component for another (and writing a thin adapter for it if it's not already available). This should also mean that the whole system can be better optimized depending on the workload type and use-case.