[aerogear-dev] [Aerogear Pipeline] Support for nested endpoints
Sebastien Blanc
scm.blanc at gmail.com
Tue Apr 30 04:16:54 EDT 2013
And to be honest even the read feels weird to me when the nestedEndpoint
also contains an Id :
READ /posts/2/comments/5
pipe.read({
id: 2,
resourcePath: "/comments/5"
});
it's not obvious here that we read comment with 5
On Tue, Apr 30, 2013 at 10:08 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
> I know I know ! I'm just writing out the stuff with the specs we have
> today ;)
>
>
>
> On Tue, Apr 30, 2013 at 10:05 AM, Corinne Krych <corinnekrych at gmail.com>wrote:
>
>> IMHO, the problem with Seb's syntax
>>
>> pipe.remove( 2 ,
>> {
>> resourcePath: "comment",
>> resourcePathId: 5
>> }
>> );
>> is that you read delete 2 and then the details of the nested structure
>> you should read delete 5 first and then the details of where to find it.
>>
>> ---
>> Corinne
>>
>>
>>
>> On 30 April 2013 09:59, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>
>>> Totally agree :) but if you want to do what you suggest without using
>>> nested resources ( just delete(5) ) you must create a complete Pipe just
>>> for "/post/2/comments" which is also not acceptable, we need to find
>>> aother of doing it.
>>>
>>>
>>>
>>> On Tue, Apr 30, 2013 at 9:56 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2013 at 9:53 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>>>
>>>>> Yes , i.e a common use case, we want to delete comment with id 5 from
>>>>> blog post with id 2 :
>>>>>
>>>>> DELETE /post/2/comment/5
>>>>>
>>>>> With the nested endpoints has we have defined it will be something
>>>>> like :
>>>>>
>>>>> pipe.remove( 2 ,
>>>>> {
>>>>> resourcePath:"comment/5"
>>>>> }
>>>>> );
>>>>>
>>>>> Which is indeed not crystal clear. But in the same time we really need
>>>>> to provide a solution.
>>>>> We could maybe introduce a "resourcePathId" ?
>>>>>
>>>>> pipe.remove( 2 ,
>>>>> {
>>>>> resourcePath: "comment",
>>>>> resourcePathId: 5
>>>>> }
>>>>> );
>>>>>
>>>>> But that would only make sense for a "one level" nested resource ...
>>>>>
>>>>
>>>>
>>>> For me, that all reads "delete 2" :)
>>>>
>>>> Not sure, but currently, that is more obvious (e.g. when you have a
>>>> pipe against "/post/2/comments", you just say delete(5);)
>>>>
>>>>
>>>> -Matthias
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 30, 2013 at 9:43 AM, Matthias Wessendorf <
>>>>> matzew 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.id set (here we assume that the teamObject has similar
>>>>>>> config_id name with league for this to work ??)
>>>>>>>
>>>>>>> Similar for remove:
>>>>>>>
>>>>>>> [leaguesPipe remove:teamObject resourcePath:"/foo/teams"]
>>>>>>>
>>>>>>> So, for cases of 'save' and 'remove', the resourcePath endpoint with
>>>>>>> the Pipe id SET must come first, and then we append the object's endpoint.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Christos
>>>>>>>
>>>>>>> On Apr 18, 2013, at 6:39 PM, Daniel Bevenius <
>>>>>>> daniel.bevenius 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
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130430/1601734e/attachment-0001.html
More information about the aerogear-dev
mailing list