Hi, I'm the developer of Orbit, which I created to enable advanced features in client-side apps such as offline mode, synchronization of local caches, undo / redo stacks, and ad hoc editing contexts. These features require a systematic approach to accessing and transforming data in multiple data sources.

Stay tuned - I'm currently working on an introductory blog post as well as detailed docs and an example app.

Edit: I just updated the readme with essentially the same use cases I mentioned above.

Maybe you should consider naming it differently, as my first thought was that it has something to do with Zurb's Orbit.js

I've had this name and concept kicking around in my head for over two years. "Orbit" seems a catchy metaphor for effortless relationships between data sources.

I'd hoped there wouldn't be confusion with a component in such a different domain (image slider vs. data), but I will consider a rename if that proves to not be the case.

Fwiw, ZURB's Orbit was my first thought too, and mattdeboard is right that changing the name will only get harder not easier.

That said, it's probably also the case that most of us will just make note of the fact that there are two Orbit.js's now and qualify which one we're referring to when needed.

There's already a significant level of confusion between the two products. The decision to change will not get any easier and the impact of a name change will only increase as you drag on. You should change it now because there's nothing gained by waiting.

hey it looks cool. i'm looking forward to the blog post. would love to see examples of killer techniques this enables. the readme is rather dense.

an example app would be awesome !