[aerogear-dev] [Aerogear Pipeline] Support for nested endpoints
Summers Pittman
supittma at redhat.com
Thu Apr 11 10:07:38 EDT 2013
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
> <mailto: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 <mailto:matzew at apache.org>> wrote:
>>
>>
>>
>>
>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman
>> <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>>
>>
>>
>> ----- Original Message -----
>> | From: "Matthias Wessendorf" <matzew at apache.org
>> <mailto:matzew at apache.org>>
>> | To: "AeroGear Developer Mailing List"
>> <aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto: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 <http://www.nitrodesk.com/> )
>> |
>> |
>> | -----Original Message-----
>> | From: Matthias Wessendorf [ matzew at apache.org
>> <mailto:matzew at apache.org> ]
>> | Received: Monday, 08 Apr 2013, 12:04PM
>> | To: AeroGear Developer Mailing List [
>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto:supittma at redhat.com> >
>> | wrote:
>> |
>> | >
>> | >
>> | > ----- Original Message -----
>> | > | From: "Matthias Wessendorf" < matzew at apache.org
>> <mailto:matzew at apache.org> >
>> | > | To: "AeroGear Developer Mailing List" <
>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto: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 <mailto:matzew at apache.org>
>> | > | >
>> | > | wrote:
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > | On Fri, Apr 5, 2013 at 10:52 AM, Sebastien Blanc <
>> scm.blanc at gmail.com <mailto:scm.blanc at gmail.com> >
>> | > | wrote:
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > | On Fri, Apr 5, 2013 at 10:36 AM, Matthias Wessendorf <
>> matzew at apache.org <mailto:matzew at apache.org>
>> | > | >
>> | > | wrote:
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > | On Fri, Apr 5, 2013 at 10:14 AM, Christos Vasilakis <
>> cvasilak at gmail.com <mailto: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/ <http://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 <mailto: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
>> <mailto:cvasilak at gmail.com> >
>> | > | | To: "AeroGear Developer Mailing List" <
>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto: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
>> <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | | >
>> | > | | > _______________________________________________
>> | > | | > aerogear-dev mailing list
>> | > | | > aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | |
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> | > | | aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> | > | | aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> | > | | aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> | > | | aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > | |
>> | > | |
>> | > | | _______________________________________________
>> | > | | aerogear-dev mailing list
>> | > | | aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > |
>> | > | _______________________________________________
>> | > | aerogear-dev mailing list
>> | > | aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > |
>> | > |
>> | > | _______________________________________________
>> | > | aerogear-dev mailing list
>> | > | aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | > |
>> | > |
>> | > | _______________________________________________
>> | > | aerogear-dev mailing list
>> | > | aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | > | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> | >
>> | > _______________________________________________
>> | > aerogear-dev mailing list
>> | > aerogear-dev at lists.jboss.org
>> <mailto: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
>> <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> | https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130411/c157ceb2/attachment-0001.html
More information about the aerogear-dev
mailing list