Feature/services take2

[yankeeinlondon]

Ok basic fetch and save operations are working now in an browserify-less environment and I've started a TODO app in the dummy app

[yankeeinlondon]

Feel like progress is moving at a good clip but wanted to check in again with you and make sure you're still wanting to do this in collaboration.

[yankeeinlondon]

Keen on seeing how you're going to approach the horizon-watch adaptor. Specifically how you'll activate the adapter when "off-world" events happen in the database. I'm still not sure how to avoid using the "bad smelling" approach i started earlier. 😄

[yankeeinlondon]

Going to bed now but hope to hear from you in the morning.

[yankeeinlondon]

One last question ... in a 1:M relationship (which exists between people and todo) isn't ED meant to update the other side of the relationship if you have bi-directional relationships defined (aka, ownedBy and hasMany on the two sides).

[levimoore]

Ken and Kyle. I've been watching the progress the last few days and just wanted to offer some words of encouragement.

I've been able to get a simple app up and running with this addon (albeit with some hackery...) and I think it will be very nice to use Horizon with Ember.

No real opinions as I am pretty noob. But just wanted to say keep up the good work and thanks!!

[yankeeinlondon]

@levimoore thanks for kind words

[yankeeinlondon]

Ok, it's all working in non-real time. I'm going to add real-time in. Having dug pretty deeply into this I feel quite strongly that having separate adapters for "fetch" versus "watch" is the wrong approach. I feel that way because:

• 90% of the code across adapters is boilerplate reuse
• all that "watch" is doing is adding a method to interact with external events
• integrating it into one doesn't reduce flexibility, it actually increases it ... allowing the user to choose at a macro level on or off but also to enable/disable at a collection level too

I know that you had initially wanted to do this differently so all future work i'll do off a separate feature branch so you can accept this in but ignore my further approach if you're not ok with it. That leads me to my final point ... I haven't heard from you in days so I'm not sure where your head is. I assume you've been busy but I kinda need to know how to proceed before I start marketing it to others.

Paths forward as I see it:

1. If you're happy with the design direction i'm taking then great, nothing changes other than your acceptance of the PR. This is my preferred option.
2. If you feel the development has moved past you and you'd rather pass the repo to me then I'd accept but it would be much nicer to have a partner in crime.
3. If you don't like the design direction and still want to take it your own way then I will rename my repo and we can give the community choices

Please let me know. My goal is to have real-time working today and start marketing it Monday.