This is the same issue I pointed out this morning on Sebi's implementation. I need to
think more about a solution.
On Apr 23, 2013, at 7:33 AM, Christos Vasilakis <cvasilak(a)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(a)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(a)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(a)gmail.com> wrote:
>
>> So we all agreed on "resourcePath" ?
>>
>>
>>
>> On Thu, Apr 18, 2013 at 4:54 PM, Christos Vasilakis <cvasilak(a)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(a)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(a)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(a)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(a)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(a)redhat.com>
wrote:
>>>>
>>>>> +1 to resourcePath . it beats my thought of
"superawesomenestedresourcethingy"
>>>>> On Apr 16, 2013, at 8:39 AM, Christos Vasilakis
<cvasilak(a)gmail.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> I think it describes the feature better.
>>>>>>
>>>>>>
>>>>>> On Apr 16, 2013, at 3:09 PM, Sebastien Blanc
<scm.blanc(a)gmail.com> wrote:
>>>>>>
>>>>>>> +1 on the "resourcePath", you nailed it !
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 16, 2013 at 2:03 PM, Kris Borchers
<kris(a)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(a)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(a)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(a)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(a)apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 8, 2013 at 7:57 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> | From: "Matthias Wessendorf"
<matzew(a)apache.org>
>>>>>>>>>> | To: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>
>>>>>>>>>> | Sent: Monday, April 8, 2013 1:22:19 PM
>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline]
Support for nested endpoints
>>>>>>>>>> |
>>>>>>>>>> | OK, with the following server API:
>>>>>>>>>> |
>>>>>>>>>> |
http://some.server.com/posts/1
>>>>>>>>>> |
http://some.server.com/posts/1/comments
>>>>>>>>>> | (and NO 'comments' collection on the
'
http://some.server.com/posts/1 '
>>>>>>>>>> | response)
>>>>>>>>>> |
>>>>>>>>>> | Does this (today) 'myPipe.read(1)'
already read the specific comments (
>>>>>>>>>> |
http://some.server.com/posts/1/comments ) ??
>>>>>>>>>> |
>>>>>>>>>> | ======= JAVA API =======
>>>>>>>>>> | Class Post:
>>>>>>>>>> | - string: id;
>>>>>>>>>> | - string: title;
>>>>>>>>>> | - string: postContent;
>>>>>>>>>> | - List<Comment> comments;
>>>>>>>>>> | Class Comment:
>>>>>>>>>> | - string username;
>>>>>>>>>> | - string comment;
>>>>>>>>>> |
>>>>>>>>>> | Or would the IMPL expect an 'embedded'
_comments_ collection on the response
>>>>>>>>>> | of "GET
http://some.server.com/posts/1
" ?
>>>>>>>>>>
>>>>>>>>>> It will not read /posts/1/comments if the
Pipe's endpoint is /posts. If you have a comments collection on the post but no
comments data in the response then the value for getComments will just be null.
>>>>>>>>>>
>>>>>>>>>> Ok - so this needs to be tweaked in Java too,
since it's very common to model the REST endpoints like above;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | On Mon, Apr 8, 2013 at 7:05 PM, Summers Pittman
< supittma(a)redhat.com >
>>>>>>>>>> | wrote:
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | No. The get of pipe 1 would have to include the
comments for get comments to
>>>>>>>>>> | work
>>>>>>>>>> |
>>>>>>>>>> | Sent from my Android phone using TouchDown (
www.nitrodesk.com )
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | -----Original Message-----
>>>>>>>>>> | From: Matthias Wessendorf [ matzew(a)apache.org
]
>>>>>>>>>> | Received: Monday, 08 Apr 2013, 12:04PM
>>>>>>>>>> | To: AeroGear Developer Mailing List [
aerogear-dev(a)lists.jboss.org ]
>>>>>>>>>> | Subject: Re: [aerogear-dev] [Aerogear Pipeline]
Support for nested endpoints
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | On Mon, Apr 8, 2013 at 5:57 PM, Summers Pittman
< supittma(a)redhat.com >
>>>>>>>>>> | wrote:
>>>>>>>>>> |
>>>>>>>>>> | >
>>>>>>>>>> | >
>>>>>>>>>> | > ----- Original Message -----
>>>>>>>>>> | > | From: "Matthias Wessendorf"
< matzew(a)apache.org >
>>>>>>>>>> | > | To: "AeroGear Developer Mailing
List" < aerogear-dev(a)lists.jboss.org >
>>>>>>>>>> | > | Sent: Monday, April 8, 2013 10:28:46 AM
>>>>>>>>>> | > | Subject: Re: [aerogear-dev] [Aerogear
Pipeline] Support for nested
>>>>>>>>>> | > endpoints
>>>>>>>>>> | > |
>>>>>>>>>> | > | or, like before said - reading
"lists" (e.g. all the comments for
>>>>>>>>>> | > specific
>>>>>>>>>> | > | blog post):
>>>>>>>>>> | > |
https://gist.github.com/matzew/04f069dfbed2cc77a8b4
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | For Java.... I guess...... resolving
this URL:
>>>>>>>>>> | > |
http://some.server.com/posts/1/comments
>>>>>>>>>> | > |
>>>>>>>>>> | > | could be done with this - right ?
>>>>>>>>>> | > |
>>>>>>>>>> | > | =======
>>>>>>>>>> | > | Class Post:
>>>>>>>>>> | > | - string: title;
>>>>>>>>>> | > | - string: postContent;
>>>>>>>>>> | > | - List<Comment> comments;
>>>>>>>>>> | > | Class Comment:
>>>>>>>>>> | > | - string username;
>>>>>>>>>> | > | - string comment;
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | // get all the comments for 1:
>>>>>>>>>> | > | Post myPostOne =
postPipe.read("1");
>>>>>>>>>> | > | myPostOne.getComments();
>>>>>>>>>> | > |
>>>>>>>>>> | > | // get all the comments for 2:
>>>>>>>>>> | > | Post myPostTwo =
postPipe.read("2");
>>>>>>>>>> | > | myPostTwo.getComments();
>>>>>>>>>> | > | =======
>>>>>>>>>> | >
>>>>>>>>>> | > It can be done with that yes. My concern
was more when we had a Pipe of
>>>>>>>>>> | > type <Post> and a
readForResource(String property) method.
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | Ok - one more question
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | So... when doing: myPipe.read(1); does that
"only" issue a GET against the '
>>>>>>>>>> |
http://some.server.com/posts/1 ' resource?
>>>>>>>>>> |
>>>>>>>>>> | A second get, for the comments collection is
than issued when calling
>>>>>>>>>> | myPostOne.getComments();?
>>>>>>>>>> | (GET against '
http://some.server.com/posts/1/comments' )?
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | > The type information of the property
isn't available unless we can infer
>>>>>>>>>> | > it from the Post object.
>>>>>>>>>> | >
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | >
>>>>>>>>>> | >
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | Greetings,
>>>>>>>>>> | > | Matthias
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 2:37 PM, Matthias
Wessendorf < matzew(a)apache.org >
>>>>>>>>>> | > | wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | Thought a bit more about it and chatted
with friends,
>>>>>>>>>> | > |
>>>>>>>>>> | > | the issue with the sub pipes is: it adds
state and is perhaps an API
>>>>>>>>>> | > | construct that is a bit hard to
understand (see all the discussions here)
>>>>>>>>>> | > |
>>>>>>>>>> | > | Not sure - but currently we can access
"kid resources", with our API -
>>>>>>>>>> | > right
>>>>>>>>>> | > | ?
>>>>>>>>>> | > |
>>>>>>>>>> | > |
https://gist.github.com/matzew/6ab432e437b9a017a21d
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | Perhaps it's better to just keep it
that way? This has the benefit of
>>>>>>>>>> | > using
>>>>>>>>>> | > | an established and know API, the
different pipes are accessible via the
>>>>>>>>>> | > | pipeline object;
>>>>>>>>>> | > |
>>>>>>>>>> | > | And the code is not too much code;
it's simply an explicit pipe ...
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:56 AM,
Matthias Wessendorf < matzew(a)apache.org
>>>>>>>>>> | > | >
>>>>>>>>>> | > | wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:52 AM,
Sebastien Blanc < scm.blanc(a)gmail.com >
>>>>>>>>>> | > | wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:36 AM,
Matthias Wessendorf < matzew(a)apache.org
>>>>>>>>>> | > | >
>>>>>>>>>> | > | wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Fri, Apr 5, 2013 at 10:14 AM,
Christos Vasilakis < cvasilak(a)gmail.com
>>>>>>>>>> | > | >
>>>>>>>>>> | > | wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | Hi
>>>>>>>>>> | > |
>>>>>>>>>> | > | some comments
>>>>>>>>>> | > |
>>>>>>>>>> | > | I believe the method can't be used
since you don't know the team for the
>>>>>>>>>> | > | players so you can't retrieve the
pipe directly..right?
>>>>>>>>>> | > |
>>>>>>>>>> | > | Isn't that really up to the impl of
the rest service?
>>>>>>>>>> | > | They could return a list of
teamsHePlayed for;
>>>>>>>>>> | > |
>>>>>>>>>> | > | So, let's not tie this API to a
specific, not existing RESTful service;
>>>>>>>>>> | > |
>>>>>>>>>> | > | +1, we don't need to care about
that, we must just focus on how we can
>>>>>>>>>> | > | declare and call nested pipes.
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | yep
>>>>>>>>>> | > |
>>>>>>>>>> | > | I guess this is perhaps the closest we
can come to :
>>>>>>>>>> | > |
>>>>>>>>>> | > | id<AGPipe> allOwnersInNewYorkPipe
= [leaguesPipe subPipe:@"owners"
>>>>>>>>>> | > | for:@"newyork"];
>>>>>>>>>> | > |
>>>>>>>>>> | > | and than.... on the
'leaguesPipe' you can access its kids with something
>>>>>>>>>> | > like
>>>>>>>>>> | > | :
>>>>>>>>>> | > |
>>>>>>>>>> | > | NSArray* kids = [leaguesPipe subPipes];
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | However, that adds some state to a
specific pipe object
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | -M
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | getPlayers ( Callback < List <
Player >> callback ) {
>>>>>>>>>> | > | pipe . get ( "player" ). read
( callback );
>>>>>>>>>> | > | }
>>>>>>>>>> | > |
>>>>>>>>>> | > | Further my questions is, how is a third
(or arbitrary) nested resources
>>>>>>>>>> | > are
>>>>>>>>>> | > | supported? I mean for a url schema like
this
>>>>>>>>>> | > |
>>>>>>>>>> | > |
soccer.org/leagues/
{id}/teams/{id}/players/{id}
>>>>>>>>>> | > |
>>>>>>>>>> | > | first we access the leagues:
>>>>>>>>>> | > | ---
>>>>>>>>>> | > |
getLeagues(Callback<List<Leagues>> callback) {
>>>>>>>>>> | > |
pipe.get("leagues").read(callback);
>>>>>>>>>> | > | }
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | then the teams for this league:
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | getTeamsOnLeaque(Leaque league,
Callback<List<Team>> callback) {
>>>>>>>>>> | > |
pipe.junction("league","team").read(leaque, callback);
>>>>>>>>>> | > | }
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | ..and then we access the
"Players" for a "Team":
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | getPlayersOnTeam(Team team,
Callback<List<Player>> callback) {
>>>>>>>>>> | > |
pipe.junction("team","player").read(team, callback);
>>>>>>>>>> | > | }
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | But where is the "League"
information to fill the "/leagues/{id}..."
>>>>>>>>>> | > path?
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | I'd assume the information is
'inherited' out of a given pipe, when
>>>>>>>>>> | > doing the
>>>>>>>>>> | > | 'join'
>>>>>>>>>> | > |
>>>>>>>>>> | > | e.g. like
>>>>>>>>>> | > | myTeamsForLeaguePipe =
leaguePipe.junction("team");
>>>>>>>>>> | > |
>>>>>>>>>> | > | not sure...
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | Unless you mean something like:
>>>>>>>>>> | > | ---
>>>>>>>>>> | > | getPlayersOnTeam(Leaque league, Team
team, Callback<List<Player>>
>>>>>>>>>> | > callback) {
>>>>>>>>>> | > | pipe.junction("league",
"team","player").read(league, team, callback);
>>>>>>>>>> | > | }
>>>>>>>>>> | > |
>>>>>>>>>> | > | I am not sure if that is really easy to
understand/use
>>>>>>>>>> | > |
>>>>>>>>>> | > | Yes and the term "junction" is
a bit confusing as it don't express
>>>>>>>>>> | > explicitly
>>>>>>>>>> | > | a parent/child relation.
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | ---
>>>>>>>>>> | > |
>>>>>>>>>> | > | probably I am missing sth..
>>>>>>>>>> | > |
>>>>>>>>>> | > | Thanks,
>>>>>>>>>> | > | Christos
>>>>>>>>>> | > |
>>>>>>>>>> | > | On Apr 4, 2013, at 5:52 PM, Summers
Pittman < supittma(a)redhat.com >
>>>>>>>>>> | > wrote:
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | What if we create a new metaphor, a
Junction.
>>>>>>>>>> | > |
>>>>>>>>>> | > |
https://gist.github.com/secondsun/dcf5682b6ff17c729d9a
>>>>>>>>>> | > |
>>>>>>>>>> | > | It joins two pipes together and can be
used over and over again with
>>>>>>>>>> | > | different data?
>>>>>>>>>> | > | It isn't a Pipe though, but perhaps
that could be changed to look more
>>>>>>>>>> | > like
>>>>>>>>>> | > | Christos's previous example.
>>>>>>>>>> | > |
>>>>>>>>>> | > | At the very least I like the words
"junction" or "join" more than "of"
>>>>>>>>>> | > |
>>>>>>>>>> | > | ----- Original Message -----
>>>>>>>>>> | > | | From: "Christos Vasilakis"
< cvasilak(a)gmail.com >
>>>>>>>>>> | > | | To: "AeroGear Developer Mailing
List" < aerogear-dev(a)lists.jboss.org >
>>>>>>>>>> | > | | Sent: Wednesday, April 3, 2013 3:03:02
AM
>>>>>>>>>> | > | | Subject: Re: [aerogear-dev] [Aerogear
Pipeline] Support for nested
>>>>>>>>>> | > | | endpoints
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On Apr 2, 2013, at 4:03 PM, Matthias
Wessendorf < matzew(a)apache.org >
>>>>>>>>>> | > | | wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Two thoughts....
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | 1) the 'original' leaguesPipe
has no clue about the subpipes, right ?
>>>>>>>>>> | > | | 2) should a pipe offer a
'getter' for all it's sub pipes ?
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Just a thought is instead of using
Pipe, to continue using Pipeline
>>>>>>>>>> | > adding
>>>>>>>>>> | > | | an
>>>>>>>>>> | > | | extra parameter " of" for
specifying the parent : E.g.:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | …..
>>>>>>>>>> | > | | id<AGPipe> leaguesPipe =
[pipeline pipe@"leagues"];
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | id<AGPipe> allTeamsInSeattlePipe
= [pipeline subPipe@"teams" of
>>>>>>>>>> | > | | :leaguesPipe
>>>>>>>>>> | > | | for:@"seattle"]
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | id<AGPipe>
allPlayersInTrebuchetPipe = [pipeline subPipe:@"players"
>>>>>>>>>> | > of:
>>>>>>>>>> | > | | allTeamsInSeattlePipe
for:@"trebuchet"];
>>>>>>>>>> | > | | …..
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Wdyt?
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | -M
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Thanks,
>>>>>>>>>> | > | | Christos
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
soccer.org/leagues/seattle/teams/trebuchet/players/foo - >
>>>>>>>>>> | > | | [[pipeline pipe:@"players"
pathParams:@[@"seattle", @"trebuchet"]]
>>>>>>>>>> | > read
>>>>>>>>>> | > | | :@"foo"] ..
>>>>>>>>>> | > | | -----
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Wdyt?
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Thanks
>>>>>>>>>> | > | | Christos
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On Mar 18, 2013, at 1:12 PM, Sebastien
Blanc < scm.blanc(a)gmail.com >
>>>>>>>>>> | > wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Well, that would not be possible, for
that you will have to create a
>>>>>>>>>> | > | | "child"
>>>>>>>>>> | > | | pipe. But I agree, that is maybe no
optimal ...
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 6:44 PM,
Summers Pittman < supittma(a)redhat.com
>>>>>>>>>> | > | | >
>>>>>>>>>> | > | | wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On 03/15/2013 01:34 PM, Sebastien
Blanc wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | I like the idea but I will more see
that has a method/function for the
>>>>>>>>>> | > | | pipelineManager (and will be easier to
implement in JS, I think) :
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | var myParentPipe =
>>>>>>>>>> | >
Aerogear.Pipeline({name:"parentPipe"}).pipes.parentPipe
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | var myChildPipe =
Aerogear.Pipeline.fromParent(myParentPipe, {options}
>>>>>>>>>> | > )
>>>>>>>>>> | > | | What would it look like to get a child
record from a parent?
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On Fri, Mar 15, 2013 at 5:37 PM,
Douglas Campos < qmx(a)qmx.me > wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | What about this?
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | Pipeline<Post> postPipeline = …
>>>>>>>>>> | > | | Post post = // get from the pipeline
>>>>>>>>>> | > | | Pipeline<Comment>
>>>>>>>>>> | > | |
postPipeline.childPipelineForOrOtherWeirdName(Comment.class, post)
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | On 15/03/2013, at 12:26, Summers
Pittman < supittma(a)redhat.com >
>>>>>>>>>> | > wrote:
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | > On 03/14/2013 04:48 AM, Matthias
Wessendorf wrote:
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> On Thu, Mar 14, 2013 at 9:32
AM, Sebastien Blanc <
>>>>>>>>>> | > scm.blanc(a)gmail.com >
>>>>>>>>>> | > | | >> wrote:
>>>>>>>>>> | > | | >> Hi,
>>>>>>>>>> | > | | >> While I was playing with
scaffolding and tried to build a simple
>>>>>>>>>> | > Blog
>>>>>>>>>> | > | | >> Application with Aerogear I
faced the current situation :
>>>>>>>>>> | > | | >> I have a Post object which
contains many Comment objects. Now I
>>>>>>>>>> | > want to
>>>>>>>>>> | > | | >> call my Post pipe to retrieve
the related comments, I have
>>>>>>>>>> | > currently 2
>>>>>>>>>> | > | | >> options :
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> /posts/1 -> assuming
comments will be implicitly retrieved (eager
>>>>>>>>>> | > | | >> loading)
>>>>>>>>>> | > | | >> /comments/?postid=1
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> But regarding our model the
correct form should be :
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> /posts/1/comments
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> +1
>>>>>>>>>> | > | | >> that is the ideal way to
model URIs for "nested" resources.
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> See [1], extracted from [2]
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> But, AFAIK, with the current
API, it is not possible to define this
>>>>>>>>>> | > last
>>>>>>>>>> | > | | >> pattern (at least for JS and
iOs, confirmed by Matzew). When doing a
>>>>>>>>>> | > | | >> read
>>>>>>>>>> | > | | >> we can pass an id option but
as mentioned in the doc, this id will
>>>>>>>>>> | > | | >> always
>>>>>>>>>> | > | | >> be append to the endpoint.
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> Well, it is possible - but in
a very (IMO) ugly way:
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
https://gist.github.com/matzew/6ab432e437b9a017a21d
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> IMO, we should be able to
support this pattern but for now I'm not
>>>>>>>>>> | > | | >> really
>>>>>>>>>> | > | | >> sure how to specify this in
our API, so if you have any ideas
>>>>>>>>>> | > feedback
>>>>>>>>>> | > | | >> this thread has been made for
you !
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> Suggestion: Enhance the read
function - example:
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
https://gist.github.com/matzew/04f069dfbed2cc77a8b4
>>>>>>>>>> | > | | > I'm thinking of the inverse
myself. Add a "ParentPath" property
>>>>>>>>>> | > which can
>>>>>>>>>> | > | | > be used to extract information
from parent objects.
>>>>>>>>>> | > | | >
>>>>>>>>>> | > | | >
https://gist.github.com/secondsun/17ce96082eda37dbd10e
>>>>>>>>>> | > | | >
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> -Matthias
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> [1]
>>>>>>>>>> | > | | >>
>>>>>>>>>> | >
http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig...
>>>>>>>>>> | > | | >> [2]
http://www.infoq.com/articles/rest-introduction
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> Seb
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
_______________________________________________
>>>>>>>>>> | > | | >> aerogear-dev mailing list
>>>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | | >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> --
>>>>>>>>>> | > | | >> Matthias Wessendorf
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | | >> sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | | >> twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >>
_______________________________________________
>>>>>>>>>> | > | | >> aerogear-dev mailing list
>>>>>>>>>> | > | | >>
>>>>>>>>>> | > | | >> aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | | >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | | >
>>>>>>>>>> | > | | >
_______________________________________________
>>>>>>>>>> | > | | > aerogear-dev mailing list
>>>>>>>>>> | > | | > aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | | >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | -- qmx
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | --
>>>>>>>>>> | > | | Matthias Wessendorf
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | --
>>>>>>>>>> | > | | Matthias Wessendorf
>>>>>>>>>> | > | |
>>>>>>>>>> | > | | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
>>>>>>>>>> | > | |
_______________________________________________
>>>>>>>>>> | > | | aerogear-dev mailing list
>>>>>>>>>> | > | | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > | |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > |
>>>>>>>>>> | > |
_______________________________________________
>>>>>>>>>> | > | aerogear-dev mailing list
>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
_______________________________________________
>>>>>>>>>> | > | aerogear-dev mailing list
>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | --
>>>>>>>>>> | > | Matthias Wessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > |
_______________________________________________
>>>>>>>>>> | > | aerogear-dev mailing list
>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
_______________________________________________
>>>>>>>>>> | > | aerogear-dev mailing list
>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | --
>>>>>>>>>> | > | Matthias Wessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | --
>>>>>>>>>> | > | Matthias Wessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > |
>>>>>>>>>> | > | --
>>>>>>>>>> | > | Matthias Wessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | > | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | > | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> | > |
>>>>>>>>>> | > |
_______________________________________________
>>>>>>>>>> | > | aerogear-dev mailing list
>>>>>>>>>> | > | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | > |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | >
>>>>>>>>>> | >
_______________________________________________
>>>>>>>>>> | > aerogear-dev mailing list
>>>>>>>>>> | > aerogear-dev(a)lists.jboss.org
>>>>>>>>>> | >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> | >
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | --
>>>>>>>>>> | Matthias Wessendorf
>>>>>>>>>> |
>>>>>>>>>> | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> |
>>>>>>>>>> |
_______________________________________________
>>>>>>>>>> | aerogear-dev mailing list
>>>>>>>>>> | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> |
>>>>>>>>>> | --
>>>>>>>>>> | Matthias Wessendorf
>>>>>>>>>> |
>>>>>>>>>> | blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> | sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> | twitter:
http://twitter.com/mwessendorf
>>>>>>>>>> |
>>>>>>>>>> |
_______________________________________________
>>>>>>>>>> | aerogear-dev mailing list
>>>>>>>>>> | aerogear-dev(a)lists.jboss.org
>>>>>>>>>> |
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matthias Wessendorf
>>>>>>>>>>
>>>>>>>>>> blog:
http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> sessions:
http://www.slideshare.net/mwessendorf
>>>>>>>>>> twitter:
http://twitter.com/mwessendorf
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev