search

scttnlsn / backbone.io

Backbone.js sync via Socket.IO
http://scttnlsn.github.io/backbone.io
541 stars 66 forks source link

split listen to setupSync and listen #39

Closed mkuklis closed 11 years ago

mkuklis commented 11 years ago

Hi Scott, I ran into a situation where my own code initializes socket.io with

var io = socketio.listen(server);

but I still would like to use backbone.io. I moved out a part of to the listen function to a separate function setupSync (not sure about the name here). This allows me to just call setupSync from my own code and pass io as a parameter.

I'm not sure if this is the best way to handle it. Perhaps another way would be to refactor listen function and check if io is attached to options?

Anyway I wonder what do you think about it?

mkuklis commented 11 years ago

Oh I think this could be related to #22. Any plans to incorporate it in?

scttnlsn commented 11 years ago

Hey Michal,

Thanks for the patch. This is definitely a step in the right direction...it was a mistake to ever initialize Socket.IO from inside Backbone.IO. It looks like this is backward compatible so I don't see any reason not to merge it in.

I really want to correct the heart of the problem and allow the io object to be injected into Backbone.IO. Since this will be a breaking change I also wanted to address some of the other shortcomings I've found in Backbone.IO and release a new minor version. The plan is to re-build things based on http://github.com/scttnlsn/data.io which is a re-working of the core syncing and middleware capabilities. It addresses your problem (and #22, #28) and provides much more flexibility for hooking into client connections and notification configuration. Backbone.IO will become a client-side adapter to Data.IO's simple client-side lib. I still haven't figured out if/where the bundled middleware should live (i.e. cookies, sessions, memoryStore, etc.)...perhaps a data.io-contrib repo might be the way to go. I'm also wondering if instead I should just deprecate Backbone.IO (probably just put a note in the README) and create a separate data.io-backbone repo with the Backbone adapter.

I'd love to hear your thoughts here.

mkuklis commented 11 years ago

Thank you for the explanation Scott. It makes sense. I think I like the idea of the data.io-contrib repo with a different set of adapters/plugins for data.io. Since you have a lot of users who depend on Backbone.IO maybe the way to go here is to wait with deprecation until the backbone adapter for data.io is ready. Maybe instead of deprecation you could just add a note to Backbone.IO which would point people to the data.io solution.

On the other hand I wonder how many people run into problem described above. Maybe for majority of them the basic setup which comes with Backbone.IO works well.

I think I will try to switch to data.io and see if I can write my own little adapter. I will probably have questions about it so I may bug you ;).

scttnlsn commented 11 years ago

Cool! Yeah, happy to answer any questions you have/address any bugs you find.

lemonzi commented 11 years ago

I guess you're doing as I do, which is not using the io-served client-side code in favor of a single minified script, but it would make more sense to serve it from setupSync since it's specific to backbone.io... Actually, listen should only instantiate the server, not even provide defaults for the options. What do you think?