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

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&gt; >>> | 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&gt; >>> | 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&gt; >>> | > 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&gt; >>> | > 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