71–80 of 147 posts
Earlier quoted context omitted.
Hoodie does server-side validation of untrusted data.
Not yet. https://github.com/espy/hoodie-plugin-tutorial "This document describes functionality and features that don't exist yet."
Earlier quoted context omitted.
Yeah, it’s a document database, uses UUIDs and revisions for identification and does HTTP-based P2P replication. In Hoodie we abstract that away in a simple to use `hoodie.store` object with the usual `add()`, `update(), `find()`, `findAll()` methods for operations. No need to know about the CouchDB/PouchDB specifics, just store your objects :)
Okay, but the key design decision in any data syncing library is how it resolves update conflicts. Is it last-one-wins, report an error and try again, diff merging, or maybe some kind of operational transform? Since that's the heart of the problem being solved, it's weird when the docs leave it out.
Conflicts are detected for you, like in version control systems. You need to resolve them yourself, or you can implement a server-wins/client-wins/last-write-wins scenario, if you want to.
So let's just deliver all our business logic as JavaScript to an entirely untrustworthy client! Whats the worst that could happen?
Desktop clients have been delivering business logic to clients for a very long time with few problems. Web powered apps are similar. The issues involve protecting data stored in the cloud, communicating over secure channels and client security. JavaScript powered applications running in a browser have many security considerations, but they're manageable if you have security aware engineers building your application.…
Team Hoodie here. Happy to answer any questions you might have :)
would like to know a bit more about comparisons with other realtime & offline-syncable BAAS like: Meteor, Firebase, AngularFire etc - As a non-dev, this looks very appealing, but before I start learning I wanted to know more about the strengths/weaknesses compared to others.
Meteor is about exposing backend and frontend APIs to the browser. Hoodie hides backend complexity as much as it can. The target audiences are very different. Hoodie aims for more frobtendy/designery types, in the future Hoodie definitely wants to reach non-coders as well.
Firebase and Meteor have likely seen more development time, because Hoodie is supported by a bootstrapped company that works on Hoodie part-time and puts it’s profits into future Hoodie development. That way Hoodie moves slower, but Hoodie won’t be at a crossroads when VC funding runs out, or expected growth isn’t big enough.
As far as I can tell, Hoodie’s offline/sync/p2p story is more solid than any other solutions, but then, I’m heavily biased :)
Hoodie’s focus on clean and simple APIs also makes it more easy for beginners.
Giving full email privileges to the client is a terrible idea. Even if you do rate limiting, you're essentially allowing anyone to get your mail server(s) blacklisted and all future mail from anyone marked as spam. In general, most people would be naturally apprehensive about federating their entire user authentication system through a third party. However, I suppose that by using hoodie you are supporting a group of…
Hoodie doesn't provide any email privileges in it's core. There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app. The plugin is maybe 10 lines of code, you can easily use that as base and put all the security in it that you would do in a REST API as well. I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It…
You do realize that by putting it in your documentation, you're encouraging people to use it.
Earlier quoted context omitted.
would like to know a bit more about comparisons with other realtime & offline-syncable BAAS like: Meteor, Firebase, AngularFire etc - As a non-dev, this looks very appealing, but before I start learning I wanted to know more about the strengths/weaknesses compared to others.
Hoodie is Open Source and more like BYOBAAS (Bring Your Own Backend As A Service), you can host it yourself, or pay someone to host it for you. You are not beholden to single company’s VCs. Meteor is about exposing backend and frontend APIs to the browser. Hoodie hides backend complexity as much as it can. The target audiences are very different. Hoodie aims for more frobtendy/designery types, in the future Hoodie de…
You guys should take a look at http://github.com/EGreg/Q Not released yet -- but if someone has PHP / JS / PhoneGap skillz and wants to work with us, you can be an early member of the community.
In case you were unaware, there's a very popular and lovely promises library for javascript named q. https://github.com/kriskowal/q
There are also several languages named Q. I don't think "Q Platform" is the same thing as a promises framework. It's not even for Javascript only. So why downvote the platform because there is something named similar to it?
Another example: http://en.wikipedia.org/wiki/X_Window_authorization
https://dev.twitter.com/docs/oauth/xauth
https://www.google.com/support/enterprise/static/postini/doc...