[aerogear-dev] [Aerogear Pipeline] Support for nested endpoints
Sebastien Blanc
scm.blanc at gmail.com
Tue Apr 30 03:53:28 EDT 2013
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 ...
On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
>
> On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers <kris at redhat.com> 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 at gmail.com>
>> 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.idset (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 at gmail.com>
>> wrote:
>>
>> Yeah, I'm all for 'resourcePath' now that I'm not as confused anymore :)
>>
>>
>> On 18 April 2013 17:37, Christos Vasilakis <cvasilak at gmail.com> 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 at gmail.com>
>>> wrote:
>>>
>>> So we all agreed on "resourcePath" ?
>>>
>>>
>>>
>>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak at gmail.com>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 at gmail.com>
>>>> 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 at redhat.com> 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 at gmail.com> 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 at redhat.com> 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 at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> +1 to resourcePath . it beats my thought of
>>>>>> "superawesomenestedresourcethingy"
>>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis <cvasilak at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I think it describes the feature better.
>>>>>>
>>>>>>
>>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> +1 on the "resourcePath", you nailed it !
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers <kris at redhat.com>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 at gmail.com>
>>>>>>> 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 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
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130430/165eef4b/attachment-0001.html
More information about the aerogear-dev
mailing list