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)

- 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'.

* 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.

- the 'delete' is public; the others (e.g. post) not...

* 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_).

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).

On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen@thoughtcraft.com<javascript:;>> 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.

> >> 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <javascript:;> https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Saturday, September 15, 2012, Kris Borchers wrote: > > > On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)thoughtcraft.com&gt; 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 > > > > > > _______________________________________________ > > 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 -- 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

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&gt; wrote: > > On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Saturday, September 15, 2012, Kris Borchers wrote: >> >> >> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)thoughtcraft.com&gt; 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

:) 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&gt; 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&gt; 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&gt; wrote: >>> >>> On Sep 15, 2012, at 12:13 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> On Saturday, September 15, 2012, Kris Borchers wrote: >>>> >>>> >>>> On Sep 15, 2012, at 10:53 AM, Glen Daniels <glen(a)thoughtcraft.com&gt; >>>> 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev