Scott, If you want to send those my way, I'd be happy to incorporate them with what I'm doing.
-ryan On Fri, Mar 21, 2014 at 12:16 PM, Scott Ganyo <[email protected]> wrote: > +1 on callbacks consistency and ensuring we version correctly for > incompatible changes. > > Scott > > P.S. I also have some monkey patches that I’ve been using over the SDK I > need to submit as patches. > > On Mar 21, 2014, at 6:56 AM, Rod Simpson <[email protected]> wrote: > > > +1 on the validation. We did the dupe check initially because the API > returned a null-pointer error when posting a dupe instead of giving you > back a message telling you the entity already exists. > > > > +1 on consistent callbacks. Much needed and would make the development > experience more predictable. > > > > We should consider incrementing the major version number since this > would break backwards compatibility. > > > > > > > > -- > > Rod Simpson > > @rockerston > > rodsimpson.com > > > > On March 21, 2014 at 7:42:26 AM, Ryan Bridges ([email protected]) > wrote: > > > > Folks, > > > > I want to clean up the JS SDK to make it a bit more consistent. Among the > > top-level objects (Entity, Collection, Group, etc), There are 2 big > > inconsistencies: The validations performed before CRUD operations and the > > data supplied in the callbacks from those operations. I would prefer if > > the SDK performed no extra validation -- such as attempting to retrieve > an > > entity before updating it -- and instead performed the requested > operation > > and passed the error message back to be handled by the application. As > for > > the callbacks, some pass the response, some pass the deserialized JSON > > object, and some pass the SDK object. If all callbacks were of the > > form *function(err, > > response, self)*, the programming model would be much easier to follow > and > > repeat. > > > > Does anyone have any comments or objections? > > > > -ryan > > > > > >
