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(a)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(a)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(a)apache.org>wrote:
>
>>
>>
>>
>> On Tue, Apr 30, 2013 at 9:53 AM, Sebastien Blanc
<scm.blanc(a)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(a)apache.org
>>> > wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 23, 2013 at 2:38 PM, Kris Borchers
<kris(a)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(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
listaerogear-dev@lists.jboss.orghttps://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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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