:) I think there is no 'ideal' name for that value :)
On Mon, Sep 17, 2012 at 1:24 PM, Kris Borchers <kris(a)redhat.com> wrote:
Because not all data storage refers to this as a primary key, right?
I'm
thinking of MongoDB for example.
On Sep 16, 2012, at 2:58 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hi Kris!
One more question,
why 'recordId' instead of 'primaryKey'?
On Sunday, September 16, 2012, Matthias Wessendorf wrote:
>
> Thx!
>
> On Sat, Sep 15, 2012 at 8:27 PM, Kris Borchers <kris(a)redhat.com> wrote:
> >
> > On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org>
> > wrote:
> >
> >
> >
> > On Saturday, September 15, 2012, Kris Borchers wrote:
> >>
> >>
> >> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)thoughtcraft.com>
> >> wrote:
> >>
> >> > Hey Matthias,
> >> >
> >> > Thanks for taking a look at the prototype!
> >> >
> >> > On 9/15/12 6:12 AM, Matthias Wessendorf wrote:
> >> >> I took a quick look at the Android API. Below are a few questions:
> >> >>
> >> >> * AeroGear.java
> >> >> - Is the class 'just' a util, that offers static methods?
If so,
> >> >> should have a private ctor and be final (since a private default
> >> >> ctor
> >> >> prevents inheritance anyways)
> >> >
> >> > Yup, that's the intent, but since it's just a
"sketch" I didn't put
> >> > that
> >> > in - will do.
> >> >
> >> >> - is the API_KEY really needed? Not sure, but I think that (the
> >> >> API_KEY) is _perhaps_ something on-top of a networking client lib,
> >> >> needed when entering the real 'BaaS' market, where our lib.
is used
> >> >> against a (specific) 'backend provider'.
> >> >
> >> > Right, I was pretty much following the common BaaS pattern. It's
> >> > certainly not necessary immediately, but once we start supporting
> >> > OAuth
> >> > we'll want something like that anyway, so I put it in as a
> >> > placeholder.
> >> > Easy to remove if we decide we don't want it for now.
> >> >
> >> >> * Utils.java
> >> >> - related to the API_key, I think the X-AeroGear-Client header
needs
> >> >> to be defined/discussed - but IMO the AeroGear client lib should
> >> >> work
> >> >> also without such a key, when accessing a simple JAX-RS (read:
> >> >> RestEasy) service; Of course, when 'cloud provider' start
using our
> >> >> bits, something like API_KEY is a must.
> >> >
> >> > +1
> >> >
> >> >> - the 'delete' is public; the others (e.g. post) not...
> >> >
> >> > No semantic significance there. Should probably all be package
> >> > access,
> >> > since AeroGear is the user-facing class.
> >> >
> >> >> * Pipe.java
> >> >> - how to update an existing item?
> >> >> For instance in JS/iOS we use save which does an 'add' if
there is
> >> >> no
> >> >> _id_ or issues an 'update' if the entity already exisits
(e.g. has
> >> >> an
> >> >> _id_).
> >> >
> >> > Yep, will do that. (although note that "_id_" or
"_id" or whatever
> >> > we
> >> > use is another point of coupling ;) )
> >> I don't think it does. In JS, I have made it so that what ever name you
> >> use on the server to denote an "id", you can tell the client lib
what
> >> that
> >> name is. So whether the id field is named id or recordId, or blahblah,
> >> that
> >> is configurable when a pipe is created.
> >
> >
> > Can you post a snippet for that?
> >
> > Not exactly sure what you want to see and iOS/Android are probably going
> > to
> > have to be different but hope this helps a little.
> >
https://gist.github.com/3729174
> >
> >
> > Thx,
> > Matthias
> >
> >
> >
> >>
> >>
> >> >
> >> >> There is no concept of a 'pipeline', but I guess (at least
for now)
> >> >> on
> >> >> "Java" (aka Android) a typed list (e.g. List<Pipe>
pipeline;) is
> >> >> good
> >> >> enough, right?
> >> >> But on the other hand, than it's up to the user of the api to
> >> >> 'manage'
> >> >> all the pipes (server connections).
> >> >
> >> > Right. What sort of "management" do you imagine, other than
> >> > factory-style creation? Pipes as they stand are extremely
"cheap"
> >> > objects (no db connections, network connections, threads, etc).
> >> >
> >> > Best,
> >> > --Glen
> >> >
> >> >
> >> > ___Matthias Wessendorf
>
> blog:
http://matthiaswessendorf.wordpress.com/
> sessions:
http://www.slideshare.net/mwessendorf
> twitter:
http://twitter.com/mwessendorf
--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev