Re: [aerogear-dev] [Aerogear Pipeline] Support for nested endpoints

Totally agree :) but if you want to do what you suggest without using nested resources ( just delete(5) ) you must create a complete Pipe just for "/post/2/comments" which is also not acceptable, we need to find aother of doing it. On Tue, Apr 30, 2013 at 9:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Apr 30, 2013 at 9:53 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Yes , i.e a common use case, we want to delete comment with id 5 from >> blog post with id 2 : >> >> DELETE /post/2/comment/5 >> >> With the nested endpoints has we have defined it will be something like >> : >> >> pipe.remove( 2 , >> { >> resourcePath:"comment/5" >> } >> ); >> >> Which is indeed not crystal clear. But in the same time we really need >> to provide a solution. >> We could maybe introduce a "resourcePathId" ? >> >> pipe.remove( 2 , >> { >> resourcePath: "comment", >> resourcePathId: 5 >> } >> ); >> >> But that would only make sense for a "one level" nested resource ... >> > > > For me, that all reads "delete 2" :) > > Not sure, but currently, that is more obvious (e.g. when you have a pipe > against "/post/2/comments", you just say delete(5);) > > > -Matthias > > > >> >> >> >> On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> This is the same issue I pointed out this morning on Sebi's >>>> implementation. I need to think more about a solution. >>>> >>> >>> >>> I agree that the 'save' and the 'remove' are a bit weird (hard to >>> understand). >>> >>> -Matthias >>> >>> >>> >>>> >>>> On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; >>>> wrote: >>>> >>>> Hi, >>>> >>>> as I implement the iOS support for nested paths, and in particular >>>> 'save' and 'remove' a situation arises. >>>> >>>> Consider the 'save' operation for a new team in the following path >>>> (a pipe has been instantiated that points to 'leagues') : >>>> >>>> soccer.org/leagues/foo/teams >>>> >>>> To save a new team, the user must: >>>> >>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>> >>>> Notice that now, we NEED to pass the id of the league in the >>>> resourcePath for this to work("foo"). >>>> >>>> To update an existing team, the user must: >>>> >>>> [leaguesPipe save:teamObject resourcePath:"/foo/teams"] >>>> >>>> Again the id of the leagues needs to be passed on the resourcePath >>>> >>>> NOTE: For the update to work, teamObject is implied to have the >>>> config.id set (here we assume that the teamObject has similar >>>> config_id name with league for this to work ??) >>>> >>>> Similar for remove: >>>> >>>> [leaguesPipe remove:teamObject resourcePath:"/foo/teams"] >>>> >>>> So, for cases of 'save' and 'remove', the resourcePath endpoint with >>>> the Pipe id SET must come first, and then we append the object's endpoint. >>>> >>>> Thoughts? >>>> >>>> Thanks >>>> Christos >>>> >>>> On Apr 18, 2013, at 6:39 PM, Daniel Bevenius < >>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>> >>>> Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore >>>> :) >>>> >>>> >>>> On 18 April 2013 17:37, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >>>> >>>>> I think If no alternative comes along, let's stick to 'resourcePath' >>>>> for now.. >>>>> >>>>> >>>>> On Apr 18, 2013, at 6:23 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> So we all agreed on "resourcePath" ? >>>>> >>>>> >>>>> >>>>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis < >>>>> cvasilak(a)gmail.com&gt; wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> have created the epic to track this, feel free to edit >>>>>> >>>>>> https://issues.jboss.org/browse/AEROGEAR-1123 >>>>>> >>>>>> - >>>>>> Christos >>>>>> >>>>>> On Apr 16, 2013, at 4:23 PM, Daniel Bevenius < >>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>> >>>>>> doh! Sorry. I was just looking at the first examples in the gist and >>>>>> did not realize these could have multiple segments. >>>>>> >>>>>> >>>>>> On 16 April 2013 15:18, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Hmm, I like the idea of looking to standards but if I'm reading it >>>>>>> right, segment there means just a portion of the URI between slashes, not >>>>>>> multiple slash-separated segments. >>>>>>> >>>>>>> On Apr 16, 2013, at 8:14 AM, Daniel Bevenius < >>>>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>>>> >>>>>>> I agree, when I read resourcePath I read that as a path to >>>>>>> resource. How about pathSegment or segment as used by >>>>>>> http://tools.ietf.org/html/rfc3986#section-3.3 ? >>>>>>> >>>>>>> >>>>>>> On 16 April 2013 15:12, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> My only issue with resourcePath is that it doesn't imply that the >>>>>>>> path is relative to the current pipe. I mean, it should be implied since >>>>>>>> you're already working with a pipe and we can be explicit about that in >>>>>>>> documentation but I still wish it was somehow in the name. I think that was >>>>>>>> the goal of using "nested" in the name but I already expressed my issue >>>>>>>> with that. Any other thoughts would be appreciated but I could be happy >>>>>>>> with resourcePath. >>>>>>>> >>>>>>>> On Apr 16, 2013, at 7:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>> +1 to resourcePath . it beats my thought of >>>>>>>> "superawesomenestedresourcethingy" >>>>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis < >>>>>>>> cvasilak(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> I think it describes the feature better. >>>>>>>> >>>>>>>> >>>>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>> +1 on the "resourcePath", you nailed it ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>>>>> >>>>>>>>> Hmmm, "nestedResource" isn't terrible but not crazy about >>>>>>>>> "nested" since they're not necessarily nested but just related. Hmmmmm. >>>>>>>>> >>>>>>>>> It's not that I hate resource, I think it kind of makes sense if >>>>>>>>> you know what we're talking about. How about something like "resourcePath" >>>>>>>>> to be a little more explicit in what it is? Still not crazy about that but >>>>>>>>> feel like it's better/closer to something that describes what it is. >>>>>>>>> >>>>>>>>> On Apr 16, 2013, at 6:44 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Well, there seems to be an agreement on option #1 , except for >>>>>>>>> the name "resource" , so let's find a name that we all agree on and so we >>>>>>>>> can going further with this feature. >>>>>>>>> My propositions: "nestedResource" , "fragment", "nestedURI" ... >>>>>>>>> But I'm not really fan of all of my propositions ... >>>>>>>>> Seb >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 11, 2013 at 4:07 PM, Summers Pittman < >>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> With #1 is `resource` a URI? If so, will developers have to >>>>>>>>>> build the URI by hand? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/10/2013 10:48 AM, Christos Vasilakis wrote: >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I've prepared a document[1] that collectively describes the >>>>>>>>>> different approaches discussed in this thread for supporting the nested >>>>>>>>>> resources. It is split in two sections, ones that don't require >>>>>>>>>> modification to the existing API and ones that do >>>>>>>>>> >>>>>>>>>> Please have a look and let me know if I miss sth or interpret >>>>>>>>>> one approach wrong. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Christos >>>>>>>>>> >>>>>>>>>> [1] https://gist.github.com/cvasilak/4a5f51b8d1ad9cc7f21b >>>>>>>>>> >>>>>>>>>> On Apr 9, 2013, at 10:19 AM, Sebastien Blanc < >>>>>>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> Hey, >>>>>>>>>> Like paging, could we start 2 gists : one with a side to side >>>>>>>>>> techno samples and another one with high level Specs ? I start a bit to get >>>>>>>>>> lost in this thread :) >>>>>>>>>> Just one remark when reading the last messages, one "must have" >>>>>>>>>> is to be able to retrieve all the comments for a post without EVER >>>>>>>>>> retrieving the post record, so >>>>>>>>>> /posts/1/comments will retrieve all the comments for post 1 but >>>>>>>>>> will actually never call posts/1 : in this covered in your last examples ? >>>>>>>>>> (spec could be : "by-pass parent GET resource" >>>>>>>>>> Seb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 9, 2013 at 9:03 AM, Matthias Wessendorf < >>>>>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman < >>>>>>>>>>> supittma(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> | From: "Matthias Wessendorf" <matzew(a)apache.org&gt; >>>>>>>>>>>> | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org&gt; >>>>>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM >>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>>>> nested endpoints >>>>>>>>>>>> | >>>>>>>>>>>> | OK, with the following server API: >>>>>>>>>>>> | >>>>>>>>>>>> | http://some.server.com/posts/1 >>>>>>>>>>>> | http://some.server.com/posts/1/comments >>>>>>>>>>>> | (and NO 'comments' collection on the ' >>>>>>>>>>>> http://some.server.com/posts/1 ' >>>>>>>>>>>> | response) >>>>>>>>>>>> | >>>>>>>>>>>> | Does this (today) 'myPipe.read(1)' already read the specific >>>>>>>>>>>> comments ( >>>>>>>>>>>> | http://some.server.com/posts/1/comments ) ?? >>>>>>>>>>>> | >>>>>>>>>>>> | ======= JAVA API ======= >>>>>>>>>>>> | Class Post: >>>>>>>>>>>> | - string: id; >>>>>>>>>>>> | - string: title; >>>>>>>>>>>> | - string: postContent; >>>>>>>>>>>> | - List<Comment> comments; >>>>>>>>>>>> | Class Comment: >>>>>>>>>>>> | - string username; >>>>>>>>>>>> | - string comment; >>>>>>>>>>>> | >>>>>>>>>>>> | Or would the IMPL expect an 'embedded' _comments_ collection >>>>>>>>>>>> on the response >>>>>>>>>>>> | of "GET http://some.server.com/posts/1 " ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It will not read /posts/1/comments if the Pipe's endpoint is >>>>>>>>>>>> /posts. If you have a comments collection on the post but no comments data >>>>>>>>>>>> in the response then the value for getComments will just be null. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok - so this needs to be tweaked in Java too, since it's very >>>>>>>>>>> common to model the REST endpoints like above; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | wrote: >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | No. The get of pipe 1 would have to include the comments for >>>>>>>>>>>> get comments to >>>>>>>>>>>> | work >>>>>>>>>>>> | >>>>>>>>>>>> | Sent from my Android phone using TouchDown ( >>>>>>>>>>>> www.nitrodesk.com ) >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | -----Original Message----- >>>>>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org ] >>>>>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM >>>>>>>>>>>> | To: AeroGear Developer Mailing List [ >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org ] >>>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support for >>>>>>>>>>>> nested endpoints >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | wrote: >>>>>>>>>>>> | >>>>>>>>>>>> | > >>>>>>>>>>>> | > >>>>>>>>>>>> | > ----- Original Message ----- >>>>>>>>>>>> | > | From: "Matthias Wessendorf" < matzew(a)apache.org > >>>>>>>>>>>> | > | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM >>>>>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear Pipeline] Support >>>>>>>>>>>> for nested >>>>>>>>>>>> | > endpoints >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | or, like before said - reading "lists" (e.g. all the >>>>>>>>>>>> comments for >>>>>>>>>>>> | > specific >>>>>>>>>>>> | > | blog post): >>>>>>>>>>>> | > | https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | For Java.... I guess...... resolving this URL: >>>>>>>>>>>> | > | http://some.server.com/posts/1/comments >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | could be done with this - right ? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | ======= >>>>>>>>>>>> | > | Class Post: >>>>>>>>>>>> | > | - string: title; >>>>>>>>>>>> | > | - string: postContent; >>>>>>>>>>>> | > | - List<Comment> comments; >>>>>>>>>>>> | > | Class Comment: >>>>>>>>>>>> | > | - string username; >>>>>>>>>>>> | > | - string comment; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | // get all the comments for 1: >>>>>>>>>>>> | > | Post myPostOne = postPipe.read("1"); >>>>>>>>>>>> | > | myPostOne.getComments(); >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | // get all the comments for 2: >>>>>>>>>>>> | > | Post myPostTwo = postPipe.read("2"); >>>>>>>>>>>> | > | myPostTwo.getComments(); >>>>>>>>>>>> | > | ======= >>>>>>>>>>>> | > >>>>>>>>>>>> | > It can be done with that yes. My concern was more when we >>>>>>>>>>>> had a Pipe of >>>>>>>>>>>> | > type <Post> and a readForResource(String property) method. >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | Ok - one more question >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | So... when doing: myPipe.read(1); does that "only" issue a >>>>>>>>>>>> GET against the ' >>>>>>>>>>>> | http://some.server.com/posts/1 ' resource? >>>>>>>>>>>> | >>>>>>>>>>>> | A second get, for the comments collection is than issued >>>>>>>>>>>> when calling >>>>>>>>>>>> | myPostOne.getComments();? >>>>>>>>>>>> | (GET against ' http://some.server.com/posts/1/comments' )? >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | > The type information of the property isn't available >>>>>>>>>>>> unless we can infer >>>>>>>>>>>> | > it from the Post object. >>>>>>>>>>>> | > >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | > >>>>>>>>>>>> | > >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Greetings, >>>>>>>>>>>> | > | Matthias >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Thought a bit more about it and chatted with friends, >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | the issue with the sub pipes is: it adds state and is >>>>>>>>>>>> perhaps an API >>>>>>>>>>>> | > | construct that is a bit hard to understand (see all the >>>>>>>>>>>> discussions here) >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Not sure - but currently we can access "kid resources", >>>>>>>>>>>> with our API - >>>>>>>>>>>> | > right >>>>>>>>>>>> | > | ? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Perhaps it's better to just keep it that way? This has >>>>>>>>>>>> the benefit of >>>>>>>>>>>> | > using >>>>>>>>>>>> | > | an established and know API, the different pipes are >>>>>>>>>>>> accessible via the >>>>>>>>>>>> | > | pipeline object; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | And the code is not too much code; it's simply an >>>>>>>>>>>> explicit pipe ... >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc < >>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis < >>>>>>>>>>>> cvasilak(a)gmail.com >>>>>>>>>>>> | > | > >>>>>>>>>>>> | > | wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Hi >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | some comments >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I believe the method can't be used since you don't know >>>>>>>>>>>> the team for the >>>>>>>>>>>> | > | players so you can't retrieve the pipe directly..right? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Isn't that really up to the impl of the rest service? >>>>>>>>>>>> | > | They could return a list of teamsHePlayed for; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | So, let's not tie this API to a specific, not existing >>>>>>>>>>>> RESTful service; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | +1, we don't need to care about that, we must just focus >>>>>>>>>>>> on how we can >>>>>>>>>>>> | > | declare and call nested pipes. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | yep >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I guess this is perhaps the closest we can come to : >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe = [leaguesPipe >>>>>>>>>>>> subPipe:@"owners" >>>>>>>>>>>> | > | for:@"newyork"]; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | and than.... on the 'leaguesPipe' you can access its >>>>>>>>>>>> kids with something >>>>>>>>>>>> | > like >>>>>>>>>>>> | > | : >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes]; >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | However, that adds some state to a specific pipe object >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -M >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | getPlayers ( Callback < List < Player >> callback ) { >>>>>>>>>>>> | > | pipe . get ( "player" ). read ( callback ); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Further my questions is, how is a third (or arbitrary) >>>>>>>>>>>> nested resources >>>>>>>>>>>> | > are >>>>>>>>>>>> | > | supported? I mean for a url schema like this >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | soccer.org/leagues/ {id}/teams/{id}/players/{id} >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | first we access the leagues: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getLeagues(Callback<List<Leagues>> callback) { >>>>>>>>>>>> | > | pipe.get("leagues").read(callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | then the teams for this league: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getTeamsOnLeaque(Leaque league, Callback<List<Team>> >>>>>>>>>>>> callback) { >>>>>>>>>>>> | > | pipe.junction("league","team").read(leaque, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | ..and then we access the "Players" for a "Team": >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getPlayersOnTeam(Team team, Callback<List<Player>> >>>>>>>>>>>> callback) { >>>>>>>>>>>> | > | pipe.junction("team","player").read(team, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | But where is the "League" information to fill the >>>>>>>>>>>> "/leagues/{id}..." >>>>>>>>>>>> | > path? >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I'd assume the information is 'inherited' out of a given >>>>>>>>>>>> pipe, when >>>>>>>>>>>> | > doing the >>>>>>>>>>>> | > | 'join' >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | e.g. like >>>>>>>>>>>> | > | myTeamsForLeaguePipe = leaguePipe.junction("team"); >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | not sure... >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Unless you mean something like: >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team team, >>>>>>>>>>>> Callback<List<Player>> >>>>>>>>>>>> | > callback) { >>>>>>>>>>>> | > | pipe.junction("league", "team","player").read(league, >>>>>>>>>>>> team, callback); >>>>>>>>>>>> | > | } >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | I am not sure if that is really easy to understand/use >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Yes and the term "junction" is a bit confusing as it >>>>>>>>>>>> don't express >>>>>>>>>>>> | > explicitly >>>>>>>>>>>> | > | a parent/child relation. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | --- >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | probably I am missing sth.. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | Thanks, >>>>>>>>>>>> | > | Christos >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | What if we create a new metaphor, a Junction. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | https://gist.github.com/secondsun/dcf5682b6ff17c729d9a >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | It joins two pipes together and can be used over and >>>>>>>>>>>> over again with >>>>>>>>>>>> | > | different data? >>>>>>>>>>>> | > | It isn't a Pipe though, but perhaps that could be >>>>>>>>>>>> changed to look more >>>>>>>>>>>> | > like >>>>>>>>>>>> | > | Christos's previous example. >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | At the very least I like the words "junction" or "join" >>>>>>>>>>>> more than "of" >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | ----- Original Message ----- >>>>>>>>>>>> | > | | From: "Christos Vasilakis" < cvasilak(a)gmail.com > >>>>>>>>>>>> | > | | To: "AeroGear Developer Mailing List" < >>>>>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02 AM >>>>>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear Pipeline] >>>>>>>>>>>> Support for nested >>>>>>>>>>>> | > | | endpoints >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias Wessendorf < >>>>>>>>>>>> matzew(a)apache.org > >>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Two thoughts.... >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | 1) the 'original' leaguesPipe has no clue about the >>>>>>>>>>>> subpipes, right ? >>>>>>>>>>>> | > | | 2) should a pipe offer a 'getter' for all it's sub >>>>>>>>>>>> pipes ? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Just a thought is instead of using Pipe, to continue >>>>>>>>>>>> using Pipeline >>>>>>>>>>>> | > adding >>>>>>>>>>>> | > | | an >>>>>>>>>>>> | > | | extra parameter " of" for specifying the parent : E.g.: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | ….. >>>>>>>>>>>> | > | | id<AGPipe> leaguesPipe = [pipeline pipe@"leagues"]; >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe = [pipeline subPipe@"teams" >>>>>>>>>>>> of >>>>>>>>>>>> | > | | :leaguesPipe >>>>>>>>>>>> | > | | for:@"seattle"] >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | id<AGPipe> allPlayersInTrebuchetPipe = [pipeline >>>>>>>>>>>> subPipe:@"players" >>>>>>>>>>>> | > of: >>>>>>>>>>>> | > | | allTeamsInSeattlePipe for:@"trebuchet"]; >>>>>>>>>>>> | > | | ….. >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | -M >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Thanks, >>>>>>>>>>>> | > | | Christos >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | soccer.org/leagues/seattle/teams/trebuchet/players/foo- > >>>>>>>>>>>> | > | | [[pipeline pipe:@"players" pathParams:@[@"seattle", >>>>>>>>>>>> @"trebuchet"]] >>>>>>>>>>>> | > read >>>>>>>>>>>> | > | | :@"foo"] .. >>>>>>>>>>>> | > | | ----- >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Wdyt? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Thanks >>>>>>>>>>>> | > | | Christos >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien Blanc < >>>>>>>>>>>> scm.blanc(a)gmail.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Well, that would not be possible, for that you will >>>>>>>>>>>> have to create a >>>>>>>>>>>> | > | | "child" >>>>>>>>>>>> | > | | pipe. But I agree, that is maybe no optimal ... >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien Blanc wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | I like the idea but I will more see that has a >>>>>>>>>>>> method/function for the >>>>>>>>>>>> | > | | pipelineManager (and will be easier to implement in >>>>>>>>>>>> JS, I think) : >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | var myParentPipe = >>>>>>>>>>>> | > Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | var myChildPipe = >>>>>>>>>>>> Aerogear.Pipeline.fromParent(myParentPipe, {options} >>>>>>>>>>>> | > ) >>>>>>>>>>>> | > | | What would it look like to get a child record from a >>>>>>>>>>>> parent? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM, Douglas Campos < >>>>>>>>>>>> qmx(a)qmx.me > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | What about this? >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | Pipeline<Post> postPipeline = … >>>>>>>>>>>> | > | | Post post = // get from the pipeline >>>>>>>>>>>> | > | | Pipeline<Comment> >>>>>>>>>>>> | > | | >>>>>>>>>>>> postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post) >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers Pittman < >>>>>>>>>>>> supittma(a)redhat.com > >>>>>>>>>>>> | > wrote: >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias Wessendorf wrote: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32 AM, Sebastien Blanc < >>>>>>>>>>>> | > scm.blanc(a)gmail.com > >>>>>>>>>>>> | > | | >> wrote: >>>>>>>>>>>> | > | | >> Hi, >>>>>>>>>>>> | > | | >> While I was playing with scaffolding and tried to >>>>>>>>>>>> build a simple >>>>>>>>>>>> | > Blog >>>>>>>>>>>> | > | | >> Application with Aerogear I faced the current >>>>>>>>>>>> situation : >>>>>>>>>>>> | > | | >> I have a Post object which contains many Comment >>>>>>>>>>>> objects. Now I >>>>>>>>>>>> | > want to >>>>>>>>>>>> | > | | >> call my Post pipe to retrieve the related comments, >>>>>>>>>>>> I have >>>>>>>>>>>> | > currently 2 >>>>>>>>>>>> | > | | >> options : >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> /posts/1 -> assuming comments will be implicitly >>>>>>>>>>>> retrieved (eager >>>>>>>>>>>> | > | | >> loading) >>>>>>>>>>>> | > | | >> /comments/?postid=1 >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> But regarding our model the correct form should be : >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> /posts/1/comments >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> +1 >>>>>>>>>>>> | > | | >> that is the ideal way to model URIs for "nested" >>>>>>>>>>>> resources. >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> See [1], extracted from [2] >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> But, AFAIK, with the current API, it is not >>>>>>>>>>>> possible to define this >>>>>>>>>>>> | > last >>>>>>>>>>>> | > | | >> pattern (at least for JS and iOs, confirmed by >>>>>>>>>>>> Matzew). When doing a >>>>>>>>>>>> | > | | >> read >>>>>>>>>>>> | > | | >> we can pass an id option but as mentioned in the >>>>>>>>>>>> doc, this id will >>>>>>>>>>>> | > | | >> always >>>>>>>>>>>> | > | | >> be append to the endpoint. >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Well, it is possible - but in a very (IMO) ugly way: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> https://gist.github.com/matzew/6ab432e437b9a017a21d >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> IMO, we should be able to support this pattern but >>>>>>>>>>>> for now I'm not >>>>>>>>>>>> | > | | >> really >>>>>>>>>>>> | > | | >> sure how to specify this in our API, so if you have >>>>>>>>>>>> any ideas >>>>>>>>>>>> | > feedback >>>>>>>>>>>> | > | | >> this thread has been made for you ! >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Suggestion: Enhance the read function - example: >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> https://gist.github.com/matzew/04f069dfbed2cc77a8b4 >>>>>>>>>>>> | > | | > I'm thinking of the inverse myself. Add a >>>>>>>>>>>> "ParentPath" property >>>>>>>>>>>> | > which can >>>>>>>>>>>> | > | | > be used to extract information from parent objects. >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | > >>>>>>>>>>>> https://gist.github.com/secondsun/17ce96082eda37dbd10e >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> -Matthias >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> [1] >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > >>>>>>>>>>>> http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig... >>>>>>>>>>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> Seb >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> >>>>>>>>>>>> | > | | >> _______________________________________________ >>>>>>>>>>>> | > | | >> 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 >>>>>>>>>>>> | > | | > >>>>>>>>>>>> | > | | > _______________________________________________ >>>>>>>>>>>> | > | | > aerogear-dev mailing list >>>>>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org >>>>>>>>>>>> | > | | > >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | -- qmx >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | 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 >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | 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 >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | 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 >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | 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 >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | >>>>>>>>>>>> | > | | _______________________________________________ >>>>>>>>>>>> | > | | 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 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | 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 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | _______________________________________________ >>>>>>>>>>>> | > | 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 >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -- >>>>>>>>>>>> | > | Matthias Wessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>> | > | sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>> | > | twitter: http://twitter.com/mwessendorf >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | >>>>>>>>>>>> | > | -- >>>>>>>>>>>> | > | 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 >>>>>>>>>>>> | > >>>>>>>>>>>> | > _______________________________________________ >>>>>>>>>>>> | > 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 >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> | -- >>>>>>>>>>>> | 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 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev