We really need a library/software name registry of some form.

http://foundation.zurb.com/docs/components/orbit.html

[domain]-descriptor-[giberish]

In this case: js-synchronized-orbits

Or, renamed for the JavaScript pattern: SynchronizedOrbit.js or orbsync.js

If we all followed this pattern, it would be nice to then have a registry for [domain]-[giberish] pairs, but really we can get away without one for a very long time.

A few examples: Django-registration becomes django-registration-valet Django-Facebook becomes django-facebook-elite Django-zebra becomes django-stripe-zebra (they have the giberish part but are hard to discover by googling the problem because they don't have the descriptor)

Kinda cool, but an example of when something like this is necessary would be nice.

The docs should start with: Why do I need this?

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 !

Pretty cool stuff! I think it's great that this lib is designed with extensibility in mind rather than being tightly coupled to any particular data store. I can see this being very useful for offline sync and reactive UI projects.

Love it! I actually developed an ad-hoc version of this for use in a personal project (I was syncing to local IndexedDB, the local browser's Filesystem API, and a server endpoint), and would have loved to have had this already.