Discuss. Feel free to write the problem inline as a comment or just to link to an issue or PR.
Ideally, full parity with all of Parse's REST features would be nice. Wondering how others feel?
In some ways, I'm really happy with the stability of the codebase. Everything is pretty modular and magic-free. That said, some issues like delta-saving are still bugging me.
It's a good goal to get a stable release and then maintain release vs. development branches going forward. A lot of point releases have introduced bugs.
Parse::Date is the source of the most bugs/annoyance for us. Feels like a 1.0 requirement to kill that. Posting deltas could be a big performance improvement (and generally saner way to do things) but a big overhaul, might be good as a 1.1 target. Parse::Client might deserve some cleaning up pre-1.0 too, it has some commented out code and sort of a half-attempt at being threadsafe by pulling in a barely used IronMQ dependency. Seems best to ship a non-thread-safe synchronous client with a sane way to use multiple Parse::Client objects throughout an app. Right now everything refers back to @@client but it shouldn't be a huge amount of work to fix that so you can at least pass an optional client into everything. A future release milestone might be to abstract away the network request layer entirely so we're not in charge of network behaviors and retries but instead are just built as a layer on top of one of the HTTP futures frameworks.
Maybe we setup github pages for documentation purpose rather then maintain on big README.
Imho in readme there should be only most important things like warnings, not supported or beta features notes etc
@ericcj Did you see #88? Think this is the HTTP abstraction layer which you mentioned.
My wishlist for the 1.0 is:
Also, documentation (probably with YARD?) somewhere that isn't just the readme. README would be for instructions for development, some quick examples, and a link to common issues in the wiki (which is another thing to start developing).
Another thing for 1.0: