@Resume design flaw

[Jeanfrancois Arcand]

Salut,

I've just found a design flaw with the @Resume support. Currently, when
you annoate a method with @Resume, a request to that that method will
resume *all* the suspended response. This is not right IMO, resume
should have only resumed a single suspended response...but which
one?Since we don't have the session concept by default in Jersey, it is
almost impossible to retrieve the Response that was suspended (it is
impossible)

So we need to re-work the annotations and add the notion of {id} (a
token the client can use), e.g

@Suspend({id})

and then later

@Resume({id})

to resume a single connection. Or use the
HttpServletRequest.getSession() under the hood, but I'm currently trying
to remove all use of Session as it cause all sort of issue of the
session times out and there is still suspended response associated with
the session.

What peoples thinks?

A+

--Jeanfrancois

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Á. Eduardo García]

Ok, so when you add @Resume to one method, you are not just resuming
the suspended connection because to do that you'll need to call that
method with the same connection, i.e. the suspended one, but that one
is just that, suspended. Am I, at least partially, right?

That's one of the things that was having me headhaches (or similar
word) :) so I removed it from the test I sent you.

I like the idea of IDs, and (in some small but related offtopic) I
think we'll need a good test case to catch this kind of design flaws
and test this ideas.

On 10/21/09, Jeanfrancois Arcand [via Atmosphere users mailling list]
<[hidden email]> wrote:

>
>
>
> Salut,
>
> I've just found a design flaw with the @Resume support. Currently, when
> you annoate a method with @Resume, a request to that that method will
> resume *all* the suspended response. This is not right IMO, resume
> should have only resumed a single suspended response...but which
> one?Since we don't have the session concept by default in Jersey, it is
> almost impossible to retrieve the Response that was suspended (it is
> impossible)
>
> So we need to re-work the annotations and add the notion of {id} (a
> token the client can use), e.g
>
> @Suspend({id})
>
> and then later
>
> @Resume({id})
>
> to resume a single connection. Or use the
> HttpServletRequest.getSession() under the hood, but I'm currently trying
> to remove all use of Session as it cause all sort of issue of the
> session times out and there is still suspended response associated with
> the session.
>
> What peoples thinks?
>
> A+
>
> --Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ______________________________________
> View message @
> http://n2.nabble.com/Resume-design-flaw-tp3861847p3861847.html
> To start a new topic under Atmosphere users mailling list, email
> [hidden email]
> To unsubscribe from Atmosphere users mailling list, click
> <Link Removed>
>

[Paul Sandoz]

On Oct 21, 2009, at 1:05 AM, Jeanfrancois Arcand wrote:

> Salut,
>
> I've just found a design flaw with the @Resume support. Currently,  
> when you annoate a method with @Resume, a request to that that  
> method will resume *all* the suspended response. This is not right  
> IMO, resume should have only resumed a single suspended  
> response...but which one?Since we don't have the session concept by  
> default in Jersey, it is almost impossible to retrieve the Response  
> that was suspended (it is impossible)
>
> So we need to re-work the annotations and add the notion of {id} (a  
> token the client can use), e.g
>
> @Suspend({id})
>
> and then later
>
> @Resume({id})
>
> to resume a single connection. Or use the  
> HttpServletRequest.getSession() under the hood, but I'm currently  
> trying to remove all use of Session as it cause all sort of issue of  
> the session times out and there is still suspended response  
> associated with the session.
>
> What peoples thinks?
>

Removing the dependence on HTTP sessions is i think a good idea, less  
stuff to worry about, but i suppose it does not really simplify the  
infrastructure if pushing is utilized as the connections are  
"sticky" (the point  being for RESTful system sessions break the  
stateless constraint and make it harder to scale).

How will the client/server agree on an ID for suspend?

- using a cookie?

- does it make any sense to associate the ID with the path of the URI?

I have a hunch it might be possible to support this using cookies and  
UUIDs without requiring explicit IDs. But i am not sure i understand  
everything here. The idea would be on suspend the server would send a  
cookie and that cookie can be sent by the client for the request  
associated with resume.

Paul.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[gerard davison]

Hmm,

I had though that this would make sense if it uuid was part of the URI,
so something like this:

@Path("/channel")
public class ChanneledResource
{

    @POST
    public Reponse createChannel(@Context UriBuilder u)
    {
         String uuid = ....;
         return Response.temporaryRedirect(
            info.getRequestUriBuilder().path(uuid.toString));
     }


     @Suspend
     @POST
     @Path("/{uuid}")
     public ... suspend()
     {
     }
   
     @Resume
     @POST
     @Path("/{uuid}")
     public ... suspend(....)
     {
     }
}

Each channel then becomes its own resource which means that it now makes
sense for Resume to resume all suspended connections. It would make the
API obvious to get hold of the relevant broadcaster as the name would be
derived by default from the URI of the suspended resource.

Or is the problem more subtle than this? I put this straw man forward
for someone else to demolish.

Gerard


On 21/10/2009 08:03, Paul Sandoz wrote:

>
> On Oct 21, 2009, at 1:05 AM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> I've just found a design flaw with the @Resume support. Currently,
>> when you annoate a method with @Resume, a request to that that method
>> will resume *all* the suspended response. This is not right IMO,
>> resume should have only resumed a single suspended response...but
>> which one?Since we don't have the session concept by default in
>> Jersey, it is almost impossible to retrieve the Response that was
>> suspended (it is impossible)
>>
>> So we need to re-work the annotations and add the notion of {id} (a
>> token the client can use), e.g
>>
>> @Suspend({id})
>>
>> and then later
>>
>> @Resume({id})
>>
>> to resume a single connection. Or use the
>> HttpServletRequest.getSession() under the hood, but I'm currently
>> trying to remove all use of Session as it cause all sort of issue of
>> the session times out and there is still suspended response
>> associated with the session.
>>
>> What peoples thinks?
>>
>
> Removing the dependence on HTTP sessions is i think a good idea, less
> stuff to worry about, but i suppose it does not really simplify the
> infrastructure if pushing is utilized as the connections are "sticky"
> (the point  being for RESTful system sessions break the stateless
> constraint and make it harder to scale).
>
> How will the client/server agree on an ID for suspend?
>
> - using a cookie?
>
> - does it make any sense to associate the ID with the path of the URI?
>
> I have a hunch it might be possible to support this using cookies and
> UUIDs without requiring explicit IDs. But i am not sure i understand
> everything here. The idea would be on suspend the server would send a
> cookie and that cookie can be sent by the client for the request
> associated with resume.
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Gerard Davison | Senior Principal Software Engineer | [phone]
Oracle JDeveloper Web Service Tooling Development
Oracle Corporation UK Ltd is a company incorporated in England & Wales.
Company Reg. No. 1782505.
Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.

Blog http://kingsfleet.blogspot.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Oct 21, 2009, at 2:23 PM, gerard davison wrote:

>
> Hmm,
>
> I had though that this would make sense if it uuid was part of the  
> URI, so something like this:
>
> @Path("/channel")
> public class ChanneledResource
> {
>
>   @POST
>   public Reponse createChannel(@Context UriBuilder u)
>   {
>        String uuid = ....;
>        return Response.temporaryRedirect(
>           info.getRequestUriBuilder().path(uuid.toString));
>    }
>
>
>    @Suspend
>    @POST
>    @Path("/{uuid}")
>    public ... suspend()
>    {
>    }
>       @Resume
>    @POST
>    @Path("/{uuid}")
>    public ... suspend(....)
>    {
>    }
> }
>
> Each channel then becomes its own resource which means that it now  
> makes sense for Resume to resume all suspended connections. It would  
> make the API obvious to get hold of the relevant broadcaster as the  
> name would be derived by default from the URI of the suspended  
> resource.
>
> Or is the problem more subtle than this? I put this straw man  
> forward for someone else to demolish.
>

I will add a few more bails of hay cause i was thinking along the same  
lines.

If you want server to create UUIDs the POST can return a 401 (Created)  
with the new URI. From the perspective of the client the URI is opaque.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Viktor Klang]

From an Akka-perspective I want the API consume-code to be as little boilerplatey as possible.

On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz <[hidden email]> wrote:

On Oct 21, 2009, at 2:23 PM, gerard davison wrote:

Hmm,

I had though that this would make sense if it uuid was part of the URI, so something like this:

@Path("/channel")
public class ChanneledResource
{

 @POST
 public Reponse createChannel(@Context UriBuilder u)
 {
      String uuid = ....;
      return Response.temporaryRedirect(
         info.getRequestUriBuilder().path(uuid.toString));
  }


  @Suspend
  @POST
  @Path("/{uuid}")
  public ... suspend()
  {
  }
     @Resume
  @POST
  @Path("/{uuid}")
  public ... suspend(....)
  {
  }
}

Each channel then becomes its own resource which means that it now makes sense for Resume to resume all suspended connections. It would make the API obvious to get hold of the relevant broadcaster as the name would be derived by default from the URI of the suspended resource.

Or is the problem more subtle than this? I put this straw man forward for someone else to demolish.

I will add a few more bails of hay cause i was thinking along the same lines.

If you want server to create UUIDs the POST can return a 401 (Created) with the new URI. From the perspective of the client the URI is opaque.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[gerard davison]

On 21/10/2009 13:33, Paul Sandoz wrote:

>
> On Oct 21, 2009, at 2:23 PM, gerard davison wrote:
>
>>
>> Hmm,
>>
>> I had though that this would make sense if it uuid was part of the
>> URI, so something like this:
>>
>> @Path("/channel")
>> public class ChanneledResource
>> {
>>
>>   @POST
>>   public Reponse createChannel(@Context UriBuilder u)
>>   {
>>        String uuid = ....;
>>        return Response.temporaryRedirect(
>>           info.getRequestUriBuilder().path(uuid.toString));
>>    }
>>
>>
>>    @Suspend
>>    @POST
>>    @Path("/{uuid}")
>>    public ... suspend()
>>    {
>>    }
>>       @Resume
>>    @POST
>>    @Path("/{uuid}")
>>    public ... suspend(....)
>>    {
>>    }
>> }
>>
>> Each channel then becomes its own resource which means that it now
>> makes sense for Resume to resume all suspended connections. It would
>> make the API obvious to get hold of the relevant broadcaster as the
>> name would be derived by default from the URI of the suspended resource.
>>
>> Or is the problem more subtle than this? I put this straw man forward
>> for someone else to demolish.
>>
>
> I will add a few more bails of hay cause i was thinking along the same
> lines.
>
> If you want server to create UUIDs the POST can return a 401 (Created)
> with the new URI. From the perspective of the client the URI is opaque.

I used "created" on my first go through this; but I figured that for a
Ajax client would process the temporary redirect automatically hence
saving some work on the client side. That being said I guess in most
situations the client needs to record the URI to allow it to be used in
other communications.

Gerard


>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Gerard Davison | Senior Principal Software Engineer | [phone]
Oracle JDeveloper Web Service Tooling Development
Oracle Corporation UK Ltd is a company incorporated in England & Wales.
Company Reg. No. 1782505.
Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.

Blog http://kingsfleet.blogspot.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[gerard davison]

Some javascript/style in this post has been disabled (why?)

Victor,

Since this class is a self contained pattern it could be used as a library class,  just make you resource return an instance of this class, or subtype, to create a channel for communication. Would this help with the boilerplating issue for you?

Gerard

On 21/10/2009 13:40, Viktor Klang wrote:

From an Akka-perspective I want the API consume-code to be as little boilerplatey as possible.

On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz <[hidden email]> wrote:

On Oct 21, 2009, at 2:23 PM, gerard davison wrote:

Hmm,

I had though that this would make sense if it uuid was part of the URI, so something like this:

@Path("/channel")
public class ChanneledResource
{

 @POST
 public Reponse createChannel(@Context UriBuilder u)
 {
      String uuid = ....;
      return Response.temporaryRedirect(
         info.getRequestUriBuilder().path(uuid.toString));
  }


  @Suspend
  @POST
  @Path("/{uuid}")
  public ... suspend()
  {
  }
     @Resume
  @POST
  @Path("/{uuid}")
  public ... suspend(....)
  {
  }
}

Each channel then becomes its own resource which means that it now makes sense for Resume to resume all suspended connections. It would make the API obvious to get hold of the relevant broadcaster as the name would be derived by default from the URI of the suspended resource.

Or is the problem more subtle than this? I put this straw man forward for someone else to demolish.

I will add a few more bails of hay cause i was thinking along the same lines.

If you want server to create UUIDs the POST can return a 401 (Created) with the new URI. From the perspective of the client the URI is opaque.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Viktor Klang]

On Wed, Oct 21, 2009 at 2:53 PM, gerard davison <[hidden email]> wrote:

Victor,

Since this class is a self contained pattern it could be used as a library class,  just make you resource return an instance of this class, or subtype, to create a channel for communication. Would this help with the boilerplating issue for you?

I'm not sure. Then perhaps it'd be better to remove the annotations and have the endpoints return instances of Resume<T>, Suspend<T> and Broadcast<T> and have those instances handle the rest?
 

Gerard

On 21/10/2009 13:40, Viktor Klang wrote:

From an Akka-perspective I want the API consume-code to be as little boilerplatey as possible.

On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz <[hidden email]> wrote:

On Oct 21, 2009, at 2:23 PM, gerard davison wrote:

Hmm,

I had though that this would make sense if it uuid was part of the URI, so something like this:

@Path("/channel")
public class ChanneledResource
{

 @POST
 public Reponse createChannel(@Context UriBuilder u)
 {
      String uuid = ....;
      return Response.temporaryRedirect(
         info.getRequestUriBuilder().path(uuid.toString));
  }


  @Suspend
  @POST
  @Path("/{uuid}")
  public ... suspend()
  {
  }
     @Resume
  @POST
  @Path("/{uuid}")
  public ... suspend(....)
  {
  }
}

Each channel then becomes its own resource which means that it now makes sense for Resume to resume all suspended connections. It would make the API obvious to get hold of the relevant broadcaster as the name would be derived by default from the URI of the suspended resource.

Or is the problem more subtle than this? I put this straw man forward for someone else to demolish.

I will add a few more bails of hay cause i was thinking along the same lines.

If you want server to create UUIDs the POST can return a 401 (Created) with the new URI. From the perspective of the client the URI is opaque.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

-- 
Gerard Davison | Senior Principal Software Engineer | [phone]
Oracle JDeveloper Web Service Tooling Development
Oracle Corporation UK Ltd is a company incorporated in England & Wales.
Company Reg. No. 1782505.
Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.

Blog http://kingsfleet.blogspot.com

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Jeanfrancois Arcand]

Salut,

Á. Eduardo García wrote:
> Ok, so when you add @Resume to one method, you are not just resuming
> the suspended connection because to do that you'll need to call that
> method with the same connection, i.e. the suspended one, but that one
> is just that, suspended. Am I, at least partially, right?

Right, the following scenario happens:

Browser 1 invokes @Suspend
Browser 2 invokes @Suspend
Browser 3 invokes @Suspend

Browser 1 invokes @Resume, B1/2/3 gets resumed instead of only Browser 1


>
> That's one of the things that was having me headhaches (or similar
> word) :) so I removed it from the test I sent you.
>
> I like the idea of IDs, and (in some small but related offtopic) I
> think we'll need a good test case to catch this kind of design flaws
> and test this ideas.

Thanks!

-- Jeanfrancois

>
> On 10/21/09, Jeanfrancois Arcand [via Atmosphere users mailling list]
> <[hidden email]
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3863449&i=0>>
> wrote:
>
>  >
>  >
>  >
>  > Salut,
>  >
>  > I've just found a design flaw with the @Resume support. Currently, when
>  > you annoate a method with @Resume, a request to that that method will
>  > resume *all* the suspended response. This is not right IMO, resume
>  > should have only resumed a single suspended response...but which
>  > one?Since we don't have the session concept by default in Jersey, it is
>  > almost impossible to retrieve the Response that was suspended (it is
>  > impossible)
>  >
>  > So we need to re-work the annotations and add the notion of {id} (a
>  > token the client can use), e.g
>  >
>  > @Suspend({id})
>  >
>  > and then later
>  >
>  > @Resume({id})
>  >
>  > to resume a single connection. Or use the
>  > HttpServletRequest.getSession() under the hood, but I'm currently trying
>  > to remove all use of Session as it cause all sort of issue of the
>  > session times out and there is still suspended response associated with
>  > the session.
>  >
>  > What peoples thinks?
>  >
>  > A+
>  >
>  > --Jeanfrancois
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: [hidden email]
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3863449&i=1>
>  > For additional commands, e-mail: [hidden email]
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3863449&i=2>
>  >
>  >
>  >
>  > ______________________________________
>  > View message @
>  > http://n2.nabble.com/Resume-design-flaw-tp3861847p3861847.html
>  > To start a new topic under Atmosphere users mailling list, email
>  > [hidden email]
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3863449&i=3>
>  > To unsubscribe from Atmosphere users mailling list, click
>  > <Link Removed>
>  >
>
> ------------------------------------------------------------------------
> View this message in context: Re: @Resume design flaw
> <http://n2.nabble.com/Resume-design-flaw-tp3861847p3863449.html>
> Sent from the Atmosphere users mailling list mailing list archive
> <http://n2.nabble.com/Atmosphere-users-mailling-list-f2493822.html> at
> Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Salut,

Paul Sandoz wrote:

>
> On Oct 21, 2009, at 1:05 AM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> I've just found a design flaw with the @Resume support. Currently,
>> when you annoate a method with @Resume, a request to that that method
>> will resume *all* the suspended response. This is not right IMO,
>> resume should have only resumed a single suspended response...but
>> which one?Since we don't have the session concept by default in
>> Jersey, it is almost impossible to retrieve the Response that was
>> suspended (it is impossible)
>>
>> So we need to re-work the annotations and add the notion of {id} (a
>> token the client can use), e.g
>>
>> @Suspend({id})
>>
>> and then later
>>
>> @Resume({id})
>>
>> to resume a single connection. Or use the
>> HttpServletRequest.getSession() under the hood, but I'm currently
>> trying to remove all use of Session as it cause all sort of issue of
>> the session times out and there is still suspended response associated
>> with the session.
>>
>> What peoples thinks?
>>
>
> Removing the dependence on HTTP sessions is i think a good idea, less
> stuff to worry about, but i suppose it does not really simplify the
> infrastructure if pushing is utilized as the connections are "sticky"
> (the point  being for RESTful system sessions break the stateless
> constraint and make it harder to scale).
>
> How will the client/server agree on an ID for suspend?
>
> - using a cookie?

This is almost already in place, e.g I've removed (svn r578) the Session
support by default but you can still re-enable it by adding
session-support=true in atmosphere.xml. When the session is used, it is
simple to retrieve the connection that was @Suspended. I should have a
fix today but that will not be the default.

>
> - does it make any sense to associate the ID with the path of the URI?

Yes I do think it makes more sense. Either a Cookie or a Header.

>
> I have a hunch it might be possible to support this using cookies and
> UUIDs without requiring explicit IDs. But i am not sure i understand
> everything here. The idea would be on suspend the server would send a
> cookie and that cookie can be sent by the client for the request
> associated with resume.

Yes this is what we will have once I implement the above...but it needs
a Session. We can probably add our own Cookie/UUID as well. The simple
design I have in mid would be:

   @Suspend add by default a Cookie (or Header)
   Atmosphere_ID: XXXXX

The client can grab that header and send it back.

Kind of related, in 0.5 I will add such header support to support
delivery garantee, e.g when you @Suspend @Resume, you might loose
@Broadcast inbetween reconnections. To avoid such situation we could
potentially use the header tricks.

A+

-- Jeanfrancois



>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Paul Sandoz wrote:

>
> On Oct 21, 2009, at 2:23 PM, gerard davison wrote:
>
>>
>> Hmm,
>>
>> I had though that this would make sense if it uuid was part of the
>> URI, so something like this:
>>
>> @Path("/channel")
>> public class ChanneledResource
>> {
>>
>>   @POST
>>   public Reponse createChannel(@Context UriBuilder u)
>>   {
>>        String uuid = ....;
>>        return Response.temporaryRedirect(
>>           info.getRequestUriBuilder().path(uuid.toString));
>>    }
>>
>>
>>    @Suspend
>>    @POST
>>    @Path("/{uuid}")
>>    public ... suspend()
>>    {
>>    }
>>       @Resume
>>    @POST
>>    @Path("/{uuid}")
>>    public ... suspend(....)
>>    {
>>    }
>> }
>>
>> Each channel then becomes its own resource which means that it now
>> makes sense for Resume to resume all suspended connections. It would
>> make the API obvious to get hold of the relevant broadcaster as the
>> name would be derived by default from the URI of the suspended resource.
>>
>> Or is the problem more subtle than this? I put this straw man forward
>> for someone else to demolish.
>>
>
> I will add a few more bails of hay cause i was thinking along the same
> lines.
>
> If you want server to create UUIDs the POST can return a 401 (Created)
> with the new URI. From the perspective of the client the URI is opaque.

OK I like that solution as well. I still think we should also support
the session one and the Cookies/Headers...

A+

-- Jeanfrancois



>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Á. Eduardo García]

Some javascript/style in this post has been disabled (why?)

I also like this solution (UUID) if I have understand it correctly. In our project no headers are being sent to the clients, because are removed by our proxy that do some fancy things, so Header or Cookies *maybe* will be of no use in this specific case.

On 21 Oct 2009, at 16:54, Jeanfrancois Arcand [via Atmosphere users mailling list] wrote:

Paul Sandoz wrote:

>
> If you want server to create UUIDs the POST can return a 401 (Created)
> with the new URI. From the perspective of the client the URI is opaque.

OK I like that solution as well. I still think we should also support
the session one and the Cookies/Headers...

A+

-- Jeanfrancois

Ángel Eduardo García Hernández

[hidden email]

[Jeanfrancois Arcand]

Viktor Klang wrote:

>
>
> On Wed, Oct 21, 2009 at 2:53 PM, gerard davison
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>     Victor,
>
>     Since this class is a self contained pattern it could be used as a
>     library class,  just make you resource return an instance of this
>     class, or subtype, to create a channel for communication. Would this
>     help with the boilerplating issue for you?
>
>
> I'm not sure. Then perhaps it'd be better to remove the annotations and
> have the endpoints return instances of Resume<T>, Suspend<T> and
> Broadcast<T> and have those instances handle the rest?

Hum...I like the annotation for their easy of use, but I like your idea
as well :-) If I understand you correctly, internally we would do what
Gerard is proposing? Is it a little too much, e.g this redirect being
done without the application having control of it?

A+

-- Jeanfrancois

>  
>
>
>     Gerard
>
>
>     On 21/10/2009 13:40, Viktor Klang wrote:
>>     From an Akka-perspective I want the API consume-code to be as
>>     little boilerplatey as possible.
>>
>>     On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>
>>         On Oct 21, 2009, at 2:23 PM, gerard davison wrote:
>>
>>
>>             Hmm,
>>
>>             I had though that this would make sense if it uuid was
>>             part of the URI, so something like this:
>>
>>             @Path("/channel")
>>             public class ChanneledResource
>>             {
>>
>>              @POST
>>              public Reponse createChannel(@Context UriBuilder u)
>>              {
>>                   String uuid = ....;
>>                   return Response.temporaryRedirect(
>>                      info.getRequestUriBuilder().path(uuid.toString));
>>               }
>>
>>
>>               @Suspend
>>               @POST
>>               @Path("/{uuid}")
>>               public ... suspend()
>>               {
>>               }
>>                  @Resume
>>               @POST
>>               @Path("/{uuid}")
>>               public ... suspend(....)
>>               {
>>               }
>>             }
>>
>>             Each channel then becomes its own resource which means
>>             that it now makes sense for Resume to resume all suspended
>>             connections. It would make the API obvious to get hold of
>>             the relevant broadcaster as the name would be derived by
>>             default from the URI of the suspended resource.
>>
>>             Or is the problem more subtle than this? I put this straw
>>             man forward for someone else to demolish.
>>
>>
>>         I will add a few more bails of hay cause i was thinking along
>>         the same lines.
>>
>>         If you want server to create UUIDs the POST can return a 401
>>         (Created) with the new URI. From the perspective of the client
>>         the URI is opaque.
>>
>>
>>         Paul.
>>
>>         ---------------------------------------------------------------------
>>         To unsubscribe, e-mail:
>>         [hidden email]
>>         <mailto:[hidden email]>
>>         For additional commands, e-mail:
>>         [hidden email]
>>         <mailto:[hidden email]>
>>
>>
>>
>>
>>     --
>>     Viktor Klang
>>     | "A complex system that works is invariably
>>     | found to have evolved from a simple system
>>     | that worked." - John Gall
>>
>>     Blog: klangism.blogspot.com <http://klangism.blogspot.com>
>>     Twttr: viktorklang
>>     Code: github.com/viktorklang <http://github.com/viktorklang>
>
>     --
>     Gerard Davison | Senior Principal Software Engineer | [phone]
>     Oracle JDeveloper Web Service Tooling Development
>     Oracle Corporation UK Ltd is a company incorporated in England & Wales.
>     Company Reg. No. 1782505.
>     Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>
>     Blog http://kingsfleet.blogspot.com
>
>
>
>
> --
> Viktor Klang
> | "A complex system that works is invariably
> | found to have evolved from a simple system
> | that worked." - John Gall
>
> Blog: klangism.blogspot.com <http://klangism.blogspot.com>
> Twttr: viktorklang
> Code: github.com/viktorklang <http://github.com/viktorklang>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Salut,

Á. Eduardo García wrote:
> I also like this solution (UUID) if I have understand it correctly. In
> our project no headers are being sent to the clients, because are
> removed by our proxy that do some fancy things, so Header or Cookies
> *maybe* will be of no use in this specific case.

Oh! That's something we need to do then as you are most probably not the
only one. Exploring the implementation right now.

A+

-- Jeanfrancois

>
> On 21 Oct 2009, at 16:54, Jeanfrancois Arcand [via Atmosphere users
> mailling list] wrote:
>
>>
>>
>> Paul Sandoz wrote:
>>
>> >
>> > If you want server to create UUIDs the POST can return a 401 (Created)
>> > with the new URI. From the perspective of the client the URI is opaque.
>>
>> OK I like that solution as well. I still think we should also support
>> the session one and the Cookies/Headers...
>>
>> A+
>>
>> -- Jeanfrancois
>
> Ángel Eduardo García Hernández
> [hidden email]
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3865836&i=0>
>
>
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: @Resume design flaw
> <http://n2.nabble.com/Resume-design-flaw-tp3861847p3865836.html>
> Sent from the Atmosphere users mailling list mailing list archive
> <http://n2.nabble.com/Atmosphere-users-mailling-list-f2493822.html> at
> Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Oct 21, 2009, at 5:06 PM, Jeanfrancois Arcand wrote:

>
>
> Viktor Klang wrote:
>> On Wed, Oct 21, 2009 at 2:53 PM, gerard davison <[hidden email]
>>  <mailto:[hidden email]>> wrote:
>>    Victor,
>>    Since this class is a self contained pattern it could be used as a
>>    library class,  just make you resource return an instance of this
>>    class, or subtype, to create a channel for communication. Would  
>> this
>>    help with the boilerplating issue for you?
>> I'm not sure. Then perhaps it'd be better to remove the annotations  
>> and have the endpoints return instances of Resume<T>, Suspend<T>  
>> and Broadcast<T> and have those instances handle the rest?
>
> Hum...I like the annotation for their easy of use, but I like your  
> idea as well :-) If I understand you correctly, internally we would  
> do what Gerard is proposing? Is it a little too much, e.g this  
> redirect being done without the application having control of it?
>

Not sure i understand why a redirection would occur. I did not think  
that browsers will perform an automatic redirection on 201 (Created).  
The Location header in the response declares the URI created by the  
server. The client can then chose to go to that URI. This is very  
different from say a redirection because a URI has moved.

Paul,

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Viktor Klang]

On Wed, Oct 21, 2009 at 5:06 PM, Jeanfrancois Arcand <[hidden email]> wrote:

Viktor Klang wrote:

On Wed, Oct 21, 2009 at 2:53 PM, gerard davison <[hidden email] <mailto:[hidden email]>> wrote:


   Victor,

   Since this class is a self contained pattern it could be used as a
   library class,  just make you resource return an instance of this
   class, or subtype, to create a channel for communication. Would this
   help with the boilerplating issue for you?


I'm not sure. Then perhaps it'd be better to remove the annotations and have the endpoints return instances of Resume<T>, Suspend<T> and Broadcast<T> and have those instances handle the rest?

Hum...I like the annotation for their easy of use, but I like your idea as well :-) If I understand you correctly, internally we would do what Gerard is proposing?

Possibly :)
 

Is it a little too much, e.g this redirect being done without the application having control of it?

Perhaps, one could allow customization of the handling by either subtyping the Suspend/Resume/Broadcast classes or by parametrization of instances.
What do you think?

 

A+

-- Jeanfrancois

 

   Gerard


   On 21/10/2009 13:40, Viktor Klang wrote:

   From an Akka-perspective I want the API consume-code to be as
   little boilerplatey as possible.

   On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz <[hidden email]

   <mailto:[hidden email]>> wrote:


       On Oct 21, 2009, at 2:23 PM, gerard davison wrote:


           Hmm,

           I had though that this would make sense if it uuid was
           part of the URI, so something like this:

           @Path("/channel")
           public class ChanneledResource
           {

            @POST
            public Reponse createChannel(@Context UriBuilder u)
            {
                 String uuid = ....;
                 return Response.temporaryRedirect(
                    info.getRequestUriBuilder().path(uuid.toString));
             }


             @Suspend
             @POST
             @Path("/{uuid}")
             public ... suspend()
             {
             }
                @Resume
             @POST
             @Path("/{uuid}")
             public ... suspend(....)
             {
             }
           }

           Each channel then becomes its own resource which means
           that it now makes sense for Resume to resume all suspended
           connections. It would make the API obvious to get hold of
           the relevant broadcaster as the name would be derived by
           default from the URI of the suspended resource.

           Or is the problem more subtle than this? I put this straw
           man forward for someone else to demolish.


       I will add a few more bails of hay cause i was thinking along
       the same lines.

       If you want server to create UUIDs the POST can return a 401
       (Created) with the new URI. From the perspective of the client
       the URI is opaque.


       Paul.

       ---------------------------------------------------------------------
       To unsubscribe, e-mail:
       [hidden email]

       <mailto:[hidden email]>

       For additional commands, e-mail:
       [hidden email]

       <mailto:[hidden email]>

   --    Viktor Klang
   | "A complex system that works is invariably
   | found to have evolved from a simple system
   | that worked." - John Gall

   Blog: klangism.blogspot.com <http://klangism.blogspot.com>
   Twttr: viktorklang
   Code: github.com/viktorklang <http://github.com/viktorklang>

   --    Gerard Davison | Senior Principal Software Engineer | [phone]
   Oracle JDeveloper Web Service Tooling Development
   Oracle Corporation UK Ltd is a company incorporated in England & Wales.
   Company Reg. No. 1782505.
   Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.

   Blog http://kingsfleet.blogspot.com




--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com <http://klangism.blogspot.com>
Twttr: viktorklang
Code: github.com/viktorklang <http://github.com/viktorklang>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Jeanfrancois Arcand]

Paul Sandoz wrote:

>
> On Oct 21, 2009, at 5:06 PM, Jeanfrancois Arcand wrote:
>
>>
>>
>> Viktor Klang wrote:
>>> On Wed, Oct 21, 2009 at 2:53 PM, gerard davison
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>    Victor,
>>>    Since this class is a self contained pattern it could be used as a
>>>    library class,  just make you resource return an instance of this
>>>    class, or subtype, to create a channel for communication. Would this
>>>    help with the boilerplating issue for you?
>>> I'm not sure. Then perhaps it'd be better to remove the annotations
>>> and have the endpoints return instances of Resume<T>, Suspend<T> and
>>> Broadcast<T> and have those instances handle the rest?
>>
>> Hum...I like the annotation for their easy of use, but I like your
>> idea as well :-) If I understand you correctly, internally we would do
>> what Gerard is proposing? Is it a little too much, e.g this redirect
>> being done without the application having control of it?
>>
>
> Not sure i understand why a redirection would occur. I did not think
> that browsers will perform an automatic redirection on 201 (Created).
> The Location header in the response declares the URI created by the
> server. The client can then chose to go to that URI. This is very
> different from say a redirection because a URI has moved.

Bad wording. But there is still an extra request made by the browser,
which is what worries me a little traffic wise (I know, I need to remove
my Grizzly hat here :-))

A+

-- Jeanfrancois



>
> Paul,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jeanfrancois Arcand]

Viktor Klang wrote:

>
>
> On Wed, Oct 21, 2009 at 5:06 PM, Jeanfrancois Arcand
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>
>     Viktor Klang wrote:
>
>
>
>         On Wed, Oct 21, 2009 at 2:53 PM, gerard davison
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>
>            Victor,
>
>            Since this class is a self contained pattern it could be used
>         as a
>            library class,  just make you resource return an instance of this
>            class, or subtype, to create a channel for communication.
>         Would this
>            help with the boilerplating issue for you?
>
>
>         I'm not sure. Then perhaps it'd be better to remove the
>         annotations and have the endpoints return instances of
>         Resume<T>, Suspend<T> and Broadcast<T> and have those instances
>         handle the rest?
>
>
>     Hum...I like the annotation for their easy of use, but I like your
>     idea as well :-) If I understand you correctly, internally we would
>     do what Gerard is proposing?
>
>
> Possibly :)
>  
>
>     Is it a little too much, e.g this redirect being done without the
>     application having control of it?
>
>
> Perhaps, one could allow customization of the handling by either
> subtyping the Suspend/Resume/Broadcast classes or by parametrization of
> instances.
> What do you think?

I like the idea, but I would like to "merge" the concept with the
current support for annotation...unless we think me the annotation are
useless. If we can build the annotation support on top of your proposal,
that would be really nice IMO.

A+

-- Jeanfrancois

>
>  
>
>     A+
>
>     -- Jeanfrancois
>
>
>
>          
>
>            Gerard
>
>
>            On 21/10/2009 13:40, Viktor Klang wrote:
>
>                From an Akka-perspective I want the API consume-code to be as
>                little boilerplatey as possible.
>
>                On Wed, Oct 21, 2009 at 2:33 PM, Paul Sandoz
>             <[hidden email] <mailto:[hidden email]>
>                <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>
>                    On Oct 21, 2009, at 2:23 PM, gerard davison wrote:
>
>
>                        Hmm,
>
>                        I had though that this would make sense if it
>             uuid was
>                        part of the URI, so something like this:
>
>                        @Path("/channel")
>                        public class ChanneledResource
>                        {
>
>                         @POST
>                         public Reponse createChannel(@Context UriBuilder u)
>                         {
>                              String uuid = ....;
>                              return Response.temporaryRedirect(
>                                
>             info.getRequestUriBuilder().path(uuid.toString));
>                          }
>
>
>                          @Suspend
>                          @POST
>                          @Path("/{uuid}")
>                          public ... suspend()
>                          {
>                          }
>                             @Resume
>                          @POST
>                          @Path("/{uuid}")
>                          public ... suspend(....)
>                          {
>                          }
>                        }
>
>                        Each channel then becomes its own resource which
>             means
>                        that it now makes sense for Resume to resume all
>             suspended
>                        connections. It would make the API obvious to get
>             hold of
>                        the relevant broadcaster as the name would be
>             derived by
>                        default from the URI of the suspended resource.
>
>                        Or is the problem more subtle than this? I put
>             this straw
>                        man forward for someone else to demolish.
>
>
>                    I will add a few more bails of hay cause i was
>             thinking along
>                    the same lines.
>
>                    If you want server to create UUIDs the POST can
>             return a 401
>                    (Created) with the new URI. From the perspective of
>             the client
>                    the URI is opaque.
>
>
>                    Paul.
>
>                  
>              ---------------------------------------------------------------------
>                    To unsubscribe, e-mail:
>                    [hidden email]
>             <mailto:[hidden email]>
>                    <mailto:[hidden email]
>             <mailto:[hidden email]>>
>
>                    For additional commands, e-mail:
>                    [hidden email]
>             <mailto:[hidden email]>
>                    <mailto:[hidden email]
>             <mailto:[hidden email]>>
>
>
>
>
>
>                --    Viktor Klang
>                | "A complex system that works is invariably
>                | found to have evolved from a simple system
>                | that worked." - John Gall
>
>                Blog: klangism.blogspot.com
>             <http://klangism.blogspot.com> <http://klangism.blogspot.com>
>                Twttr: viktorklang
>                Code: github.com/viktorklang
>             <http://github.com/viktorklang> <http://github.com/viktorklang>
>
>
>            --    Gerard Davison | Senior Principal Software Engineer |
>         [phone]
>            Oracle JDeveloper Web Service Tooling Development
>            Oracle Corporation UK Ltd is a company incorporated in
>         England & Wales.
>            Company Reg. No. 1782505.
>            Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>
>            Blog http://kingsfleet.blogspot.com
>
>
>
>
>         --
>         Viktor Klang
>         | "A complex system that works is invariably
>         | found to have evolved from a simple system
>         | that worked." - John Gall
>
>         Blog: klangism.blogspot.com <http://klangism.blogspot.com>
>         <http://klangism.blogspot.com>
>         Twttr: viktorklang
>         Code: github.com/viktorklang <http://github.com/viktorklang>
>         <http://github.com/viktorklang>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>
>
> --
> Viktor Klang
> | "A complex system that works is invariably
> | found to have evolved from a simple system
> | that worked." - John Gall
>
> Blog: klangism.blogspot.com <http://klangism.blogspot.com>
> Twttr: viktorklang
> Code: github.com/viktorklang <http://github.com/viktorklang>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Paul Sandoz]

On Oct 21, 2009, at 5:17 PM, Jeanfrancois Arcand wrote:

>
>
> Paul Sandoz wrote:
>> On Oct 21, 2009, at 5:06 PM, Jeanfrancois Arcand wrote:
>>>
>>>
>>> Viktor Klang wrote:
>>>> On Wed, Oct 21, 2009 at 2:53 PM, gerard davison <[hidden email]
>>>>  <mailto:[hidden email]>> wrote:
>>>>   Victor,
>>>>   Since this class is a self contained pattern it could be used  
>>>> as a
>>>>   library class,  just make you resource return an instance of this
>>>>   class, or subtype, to create a channel for communication. Would  
>>>> this
>>>>   help with the boilerplating issue for you?
>>>> I'm not sure. Then perhaps it'd be better to remove the  
>>>> annotations and have the endpoints return instances of Resume<T>,  
>>>> Suspend<T> and Broadcast<T> and have those instances handle the  
>>>> rest?
>>>
>>> Hum...I like the annotation for their easy of use, but I like your  
>>> idea as well :-) If I understand you correctly, internally we  
>>> would do what Gerard is proposing? Is it a little too much, e.g  
>>> this redirect being done without the application having control of  
>>> it?
>>>
>> Not sure i understand why a redirection would occur. I did not  
>> think that browsers will perform an automatic redirection on 201  
>> (Created). The Location header in the response declares the URI  
>> created by the server. The client can then chose to go to that URI.  
>> This is very different from say a redirection because a URI has  
>> moved.
>
> Bad wording. But there is still an extra request made by the  
> browser, which is what worries me a little traffic wise (I know, I  
> need to remove my Grizzly hat here :-))
>

 From what i can tell it does not require any additional requests, it  
just requires slightly different behavior from the client (i dunno if  
that is appropriate or not).

1) Browser sends a POST request to suspend

2) A 201 response is received with a URI, c say,  declared in the  
location header. That URI is the URI to use for
     resuming the suspended connection in 1).

3) The browser sends a request to c to resume.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]