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

Tue Apr 16 07:44:57 EDT 2013

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 at redhat.com>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 at gmail.com> 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 at apache.org>wrote:
>
>>
>>
>>
>>  On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman <supittma at redhat.com>wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>> | From: "Matthias Wessendorf" <matzew at apache.org>
>>> | To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
>>>  | 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 at 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 at apache.org ]
>>> | Received: Monday, 08 Apr 2013, 12:04PM
>>> | To: AeroGear Developer Mailing List [ aerogear-dev at 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 at redhat.com>
>>> | wrote:
>>> |
>>> | >
>>> | >
>>> | > ----- Original Message -----
>>> | > | From: "Matthias Wessendorf" < matzew at apache.org >
>>> | > | To: "AeroGear Developer Mailing List" <
>>> aerogear-dev at 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 at 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 at apache.org
>>> | > | >
>>> | > | wrote:
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc <
>>> scm.blanc at gmail.com >
>>> | > | wrote:
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf <
>>> matzew at apache.org
>>> | > | >
>>> | > | wrote:
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > |
>>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <
>>> cvasilak at 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 at 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 at gmail.com >
>>> | > | | To: "AeroGear Developer Mailing List" <
>>> aerogear-dev at 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 at 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 at 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 at 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 at 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 at 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 at 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/figure2.jpg
>>> | > | | >> [2] http://www.infoq.com/articles/rest-introduction
>>> | > | | >>
>>> | > | | >>
>>> | > | | >>
>>> | > | | >>
>>> | > | | >> Seb
>>> | > | | >>
>>> | > | | >>
>>> | > | | >> _______________________________________________
>>> | > | | >> aerogear-dev mailing list
>>> | > | | >> aerogear-dev at 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 at lists.jboss.org
>>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | | >
>>> | > | | > _______________________________________________
>>> | > | | > aerogear-dev mailing list
>>> | > | | > aerogear-dev at lists.jboss.org
>>> | > | | > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | | -- qmx
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list aerogear-dev at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at 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 at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at 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 at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > | |
>>> | > | |
>>> | > | | _______________________________________________
>>> | > | | aerogear-dev mailing list
>>> | > | | aerogear-dev at lists.jboss.org
>>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > |
>>> | > | _______________________________________________
>>> | > | aerogear-dev mailing list
>>> | > | aerogear-dev at lists.jboss.org
>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > |
>>> | > |
>>> | > | _______________________________________________
>>> | > | aerogear-dev mailing list
>>> | > | aerogear-dev at 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 at lists.jboss.org
>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | > |
>>> | > |
>>> | > | _______________________________________________
>>> | > | aerogear-dev mailing list
>>> | > | aerogear-dev at 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 at lists.jboss.org
>>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> | >
>>> | > _______________________________________________
>>> | > aerogear-dev mailing list
>>> | > aerogear-dev at 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 at 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 at lists.jboss.org
>>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>  _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130416/5ccd0a74/attachment-0001.html 