You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Louis Ryan <lr...@google.com> on 2009/05/20 02:08:17 UTC
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Rather than doing this we should do something akin to what we've done for
the JSON-RPC introspection support in osapi. i.e
1. osapi makes a gadgets.rpc to container asking for the supported methods.
2. Container returns that list in the format used for JSON-RPC's
system.listMethod
3. osapi binds the returned services in the same manner it supports it for
JSON-RPC, erasing the protocol backed ones if a name collision occurs
4. osapi will now dispatch those api calls of gadgets.rpc
On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <ji...@apache.org>wrote:
> osapi (oslite) should support user mediated requests.
> -----------------------------------------------------
>
> Key: SHINDIG-1065
> URL: https://issues.apache.org/jira/browse/SHINDIG-1065
> Project: Shindig
> Issue Type: New Feature
> Reporter: Sachin Shenoy
>
>
> According to osapi spec any request can be user mediated. (there is no more
> osapi.ui.*). Shindig to support mechanism for user mediated requests.
>
> Changes:
> - Containers can via configuration let shindig JS know which requests it
> want to be user mediated.
> - Predefined hooks are used to pass the request to the container and get
> the response back.
> - A new type of request, osapi.newUiRequest is defined to handle user
> mediated case. Even though this is in global space, it need not be visible
> to the developer directly. Developer uses the osapi as today.
> - batch.js is modified to allow handling of user mediated requests.
> - So that developer can know which request may get user mediated, every
> request exposes a boolean field userMediated (this is not part of standard
> but could be good to have something like this for future version). This
> would allow developers to write code like below,
>
> var r = osapi.activites.create();
> if (r.userMediated) {
> // skip creating activity, as I don't want to bug the user.
> } else {
> r.execute();
> }
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
RE: https://issues.apache.org/jira/browse/SHINDIG-1049
Posted by Jordan Zimmerman <jo...@shop.com>.
*bump*
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
-----Original Message-----
From: Jordan Zimmerman [mailto:jordanz@shop.com]
Sent: Thursday, May 21, 2009 11:22 AM
To: shindig-dev@incubator.apache.org
Cc: shindig-issues@incubator.apache.org; shishir.birmiwal@google.com
Subject: https://issues.apache.org/jira/browse/SHINDIG-1049
Any news on accepting https://issues.apache.org/jira/browse/SHINDIG-1049
? I'm now relying on this implementation and would like to know that it
will be accepted.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
RE: https://issues.apache.org/jira/browse/SHINDIG-1049
Posted by Jordan Zimmerman <jo...@shop.com>.
*bump*
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
-----Original Message-----
From: Jordan Zimmerman [mailto:jordanz@shop.com]
Sent: Thursday, May 21, 2009 11:22 AM
To: shindig-dev@incubator.apache.org
Cc: shindig-issues@incubator.apache.org; shishir.birmiwal@google.com
Subject: https://issues.apache.org/jira/browse/SHINDIG-1049
Any news on accepting https://issues.apache.org/jira/browse/SHINDIG-1049
? I'm now relying on this implementation and would like to know that it
will be accepted.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
https://issues.apache.org/jira/browse/SHINDIG-1049
Posted by Jordan Zimmerman <jo...@shop.com>.
Any news on accepting https://issues.apache.org/jira/browse/SHINDIG-1049
? I'm now relying on this implementation and would like to know that it
will be accepted.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jordanz@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this
message
immediately if this is an electronic communication.
Thank you.
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
Ping.
Sachin
On Tue, May 26, 2009 at 11:15 PM, Sachin Shenoy <sa...@google.com> wrote:
> Hi Louis,
>
> Could you please look into this change?
>
> Thanks,
> Sachin
>
>
> On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <sa...@google.com>wrote:
>
>> I have uploaded a new patch which does the suggested introspection.
>> Sachin
>>
>>
>> On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
>>
>>> All of these are valid approaches. We already introspect the
>>> server-endpoint
>>> for the JSON-RPC methods which gives a nice level of decoupling between
>>> gadget server and API server. Having the same in the client is certainly
>>> useful for gadget renderers that must interoperate with many containers.
>>>
>>> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
>>> wrote:
>>>
>>> > I would love to have a decoupled deployment. One thing that can be done
>>> is
>>> > to do server side introspection. Let the gadget renderer introspect the
>>> > mediated methods much like the normal methods via "mediatedMethods"
>>> call?
>>> > Sachin
>>> >
>>> > PS.
>>> > Going a step further (may be a bit too further), an endpoint could
>>> support
>>> > a
>>> > "getConfig" method. Gadget server could query that to get the json
>>> config
>>> > that would be merged with the static configuration before inserting it
>>> into
>>> > the iframe.
>>> >
>>> >
>>> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>>> >
>>> > > In many ways the binding mechanism is an implementation detail. The
>>> > > information could just as easily go in container config. The main
>>> point
>>> > is
>>> > > that the osapi code treats gadgets-rpc as just a transport for
>>> JSON-RPC
>>> > > style calls and the interfaces, packaging and format of the methods
>>> > aligns
>>> > > closely with that for the dat-backed APIs. One advantage of following
>>> > this
>>> > > design methodology is that it would easily allow a container to
>>> implement
>>> > a
>>> > > fully mediated API. The concerns with the late binding that you list
>>> are
>>> > > valid and should be weighed against the advantages of a decoupled
>>> > > deployment
>>> > > process between the container and the gadget server.
>>> > >
>>> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
>>> > > wrote:
>>> > >
>>> > > > This would change the way we get the list of mediated methods but I
>>> > guess
>>> > > > other stuff remains same?
>>> > > > Currently we are getting this list via configuration, but you
>>> suggest
>>> > it
>>> > > is
>>> > > > better to get it by introspection with the container. With client
>>> side
>>> > > > introspection I see these issues,
>>> > > >
>>> > > > 1. Race condition. I think this can be solvable, by delaying the
>>> actual
>>> > > > call
>>> > > > of gadgets.util.runOnLoadHandlers.
>>> > > > 2. We force the containers to implement the introspection method, a
>>> > > > container failing to do so would cause bad things (we would wait
>>> > > > indefinitely for the callback).
>>> > > > 3. Any delay caused by the introspection(?)
>>> > > >
>>> > > > Sachin
>>> > > >
>>> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
>>> wrote:
>>> > > >
>>> > > > > Rather than doing this we should do something akin to what we've
>>> done
>>> > > for
>>> > > > > the JSON-RPC introspection support in osapi. i.e
>>> > > > >
>>> > > > > 1. osapi makes a gadgets.rpc to container asking for the
>>> supported
>>> > > > methods.
>>> > > > > 2. Container returns that list in the format used for JSON-RPC's
>>> > > > > system.listMethod
>>> > > > > 3. osapi binds the returned services in the same manner it
>>> supports
>>> > it
>>> > > > for
>>> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
>>> occurs
>>> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
>>> > > > >
>>> > > > >
>>> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
>>> > > jira@apache.org
>>> > > > > >wrote:
>>> > > > >
>>> > > > > > osapi (oslite) should support user mediated requests.
>>> > > > > > -----------------------------------------------------
>>> > > > > >
>>> > > > > > Key: SHINDIG-1065
>>> > > > > > URL:
>>> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
>>> > > > > > Project: Shindig
>>> > > > > > Issue Type: New Feature
>>> > > > > > Reporter: Sachin Shenoy
>>> > > > > >
>>> > > > > >
>>> > > > > > According to osapi spec any request can be user mediated.
>>> (there is
>>> > > no
>>> > > > > more
>>> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
>>> > requests.
>>> > > > > >
>>> > > > > > Changes:
>>> > > > > > - Containers can via configuration let shindig JS know which
>>> > requests
>>> > > > it
>>> > > > > > want to be user mediated.
>>> > > > > > - Predefined hooks are used to pass the request to the
>>> container
>>> > and
>>> > > > get
>>> > > > > > the response back.
>>> > > > > > - A new type of request, osapi.newUiRequest is defined to
>>> handle
>>> > user
>>> > > > > > mediated case. Even though this is in global space, it need not
>>> be
>>> > > > > visible
>>> > > > > > to the developer directly. Developer uses the osapi as today.
>>> > > > > > - batch.js is modified to allow handling of user mediated
>>> requests.
>>> > > > > > - So that developer can know which request may get user
>>> mediated,
>>> > > every
>>> > > > > > request exposes a boolean field userMediated (this is not part
>>> of
>>> > > > > standard
>>> > > > > > but could be good to have something like this for future
>>> version).
>>> > > This
>>> > > > > > would allow developers to write code like below,
>>> > > > > >
>>> > > > > > var r = osapi.activites.create();
>>> > > > > > if (r.userMediated) {
>>> > > > > > // skip creating activity, as I don't want to bug the user.
>>> > > > > > } else {
>>> > > > > > r.execute();
>>> > > > > > }
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > --
>>> > > > > > This message is automatically generated by JIRA.
>>> > > > > > -
>>> > > > > > You can reply to this email to add a comment to the issue
>>> online.
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
Ping.
Sachin
On Tue, May 26, 2009 at 11:15 PM, Sachin Shenoy <sa...@google.com> wrote:
> Hi Louis,
>
> Could you please look into this change?
>
> Thanks,
> Sachin
>
>
> On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <sa...@google.com>wrote:
>
>> I have uploaded a new patch which does the suggested introspection.
>> Sachin
>>
>>
>> On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
>>
>>> All of these are valid approaches. We already introspect the
>>> server-endpoint
>>> for the JSON-RPC methods which gives a nice level of decoupling between
>>> gadget server and API server. Having the same in the client is certainly
>>> useful for gadget renderers that must interoperate with many containers.
>>>
>>> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
>>> wrote:
>>>
>>> > I would love to have a decoupled deployment. One thing that can be done
>>> is
>>> > to do server side introspection. Let the gadget renderer introspect the
>>> > mediated methods much like the normal methods via "mediatedMethods"
>>> call?
>>> > Sachin
>>> >
>>> > PS.
>>> > Going a step further (may be a bit too further), an endpoint could
>>> support
>>> > a
>>> > "getConfig" method. Gadget server could query that to get the json
>>> config
>>> > that would be merged with the static configuration before inserting it
>>> into
>>> > the iframe.
>>> >
>>> >
>>> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>>> >
>>> > > In many ways the binding mechanism is an implementation detail. The
>>> > > information could just as easily go in container config. The main
>>> point
>>> > is
>>> > > that the osapi code treats gadgets-rpc as just a transport for
>>> JSON-RPC
>>> > > style calls and the interfaces, packaging and format of the methods
>>> > aligns
>>> > > closely with that for the dat-backed APIs. One advantage of following
>>> > this
>>> > > design methodology is that it would easily allow a container to
>>> implement
>>> > a
>>> > > fully mediated API. The concerns with the late binding that you list
>>> are
>>> > > valid and should be weighed against the advantages of a decoupled
>>> > > deployment
>>> > > process between the container and the gadget server.
>>> > >
>>> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
>>> > > wrote:
>>> > >
>>> > > > This would change the way we get the list of mediated methods but I
>>> > guess
>>> > > > other stuff remains same?
>>> > > > Currently we are getting this list via configuration, but you
>>> suggest
>>> > it
>>> > > is
>>> > > > better to get it by introspection with the container. With client
>>> side
>>> > > > introspection I see these issues,
>>> > > >
>>> > > > 1. Race condition. I think this can be solvable, by delaying the
>>> actual
>>> > > > call
>>> > > > of gadgets.util.runOnLoadHandlers.
>>> > > > 2. We force the containers to implement the introspection method, a
>>> > > > container failing to do so would cause bad things (we would wait
>>> > > > indefinitely for the callback).
>>> > > > 3. Any delay caused by the introspection(?)
>>> > > >
>>> > > > Sachin
>>> > > >
>>> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
>>> wrote:
>>> > > >
>>> > > > > Rather than doing this we should do something akin to what we've
>>> done
>>> > > for
>>> > > > > the JSON-RPC introspection support in osapi. i.e
>>> > > > >
>>> > > > > 1. osapi makes a gadgets.rpc to container asking for the
>>> supported
>>> > > > methods.
>>> > > > > 2. Container returns that list in the format used for JSON-RPC's
>>> > > > > system.listMethod
>>> > > > > 3. osapi binds the returned services in the same manner it
>>> supports
>>> > it
>>> > > > for
>>> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
>>> occurs
>>> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
>>> > > > >
>>> > > > >
>>> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
>>> > > jira@apache.org
>>> > > > > >wrote:
>>> > > > >
>>> > > > > > osapi (oslite) should support user mediated requests.
>>> > > > > > -----------------------------------------------------
>>> > > > > >
>>> > > > > > Key: SHINDIG-1065
>>> > > > > > URL:
>>> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
>>> > > > > > Project: Shindig
>>> > > > > > Issue Type: New Feature
>>> > > > > > Reporter: Sachin Shenoy
>>> > > > > >
>>> > > > > >
>>> > > > > > According to osapi spec any request can be user mediated.
>>> (there is
>>> > > no
>>> > > > > more
>>> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
>>> > requests.
>>> > > > > >
>>> > > > > > Changes:
>>> > > > > > - Containers can via configuration let shindig JS know which
>>> > requests
>>> > > > it
>>> > > > > > want to be user mediated.
>>> > > > > > - Predefined hooks are used to pass the request to the
>>> container
>>> > and
>>> > > > get
>>> > > > > > the response back.
>>> > > > > > - A new type of request, osapi.newUiRequest is defined to
>>> handle
>>> > user
>>> > > > > > mediated case. Even though this is in global space, it need not
>>> be
>>> > > > > visible
>>> > > > > > to the developer directly. Developer uses the osapi as today.
>>> > > > > > - batch.js is modified to allow handling of user mediated
>>> requests.
>>> > > > > > - So that developer can know which request may get user
>>> mediated,
>>> > > every
>>> > > > > > request exposes a boolean field userMediated (this is not part
>>> of
>>> > > > > standard
>>> > > > > > but could be good to have something like this for future
>>> version).
>>> > > This
>>> > > > > > would allow developers to write code like below,
>>> > > > > >
>>> > > > > > var r = osapi.activites.create();
>>> > > > > > if (r.userMediated) {
>>> > > > > > // skip creating activity, as I don't want to bug the user.
>>> > > > > > } else {
>>> > > > > > r.execute();
>>> > > > > > }
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > --
>>> > > > > > This message is automatically generated by JIRA.
>>> > > > > > -
>>> > > > > > You can reply to this email to add a comment to the issue
>>> online.
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
Hi Louis,
Could you please look into this change?
Thanks,
Sachin
On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <sa...@google.com> wrote:
> I have uploaded a new patch which does the suggested introspection.
> Sachin
>
>
> On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
>
>> All of these are valid approaches. We already introspect the
>> server-endpoint
>> for the JSON-RPC methods which gives a nice level of decoupling between
>> gadget server and API server. Having the same in the client is certainly
>> useful for gadget renderers that must interoperate with many containers.
>>
>> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
>> wrote:
>>
>> > I would love to have a decoupled deployment. One thing that can be done
>> is
>> > to do server side introspection. Let the gadget renderer introspect the
>> > mediated methods much like the normal methods via "mediatedMethods"
>> call?
>> > Sachin
>> >
>> > PS.
>> > Going a step further (may be a bit too further), an endpoint could
>> support
>> > a
>> > "getConfig" method. Gadget server could query that to get the json
>> config
>> > that would be merged with the static configuration before inserting it
>> into
>> > the iframe.
>> >
>> >
>> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>> >
>> > > In many ways the binding mechanism is an implementation detail. The
>> > > information could just as easily go in container config. The main
>> point
>> > is
>> > > that the osapi code treats gadgets-rpc as just a transport for
>> JSON-RPC
>> > > style calls and the interfaces, packaging and format of the methods
>> > aligns
>> > > closely with that for the dat-backed APIs. One advantage of following
>> > this
>> > > design methodology is that it would easily allow a container to
>> implement
>> > a
>> > > fully mediated API. The concerns with the late binding that you list
>> are
>> > > valid and should be weighed against the advantages of a decoupled
>> > > deployment
>> > > process between the container and the gadget server.
>> > >
>> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
>> > > wrote:
>> > >
>> > > > This would change the way we get the list of mediated methods but I
>> > guess
>> > > > other stuff remains same?
>> > > > Currently we are getting this list via configuration, but you
>> suggest
>> > it
>> > > is
>> > > > better to get it by introspection with the container. With client
>> side
>> > > > introspection I see these issues,
>> > > >
>> > > > 1. Race condition. I think this can be solvable, by delaying the
>> actual
>> > > > call
>> > > > of gadgets.util.runOnLoadHandlers.
>> > > > 2. We force the containers to implement the introspection method, a
>> > > > container failing to do so would cause bad things (we would wait
>> > > > indefinitely for the callback).
>> > > > 3. Any delay caused by the introspection(?)
>> > > >
>> > > > Sachin
>> > > >
>> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
>> wrote:
>> > > >
>> > > > > Rather than doing this we should do something akin to what we've
>> done
>> > > for
>> > > > > the JSON-RPC introspection support in osapi. i.e
>> > > > >
>> > > > > 1. osapi makes a gadgets.rpc to container asking for the supported
>> > > > methods.
>> > > > > 2. Container returns that list in the format used for JSON-RPC's
>> > > > > system.listMethod
>> > > > > 3. osapi binds the returned services in the same manner it
>> supports
>> > it
>> > > > for
>> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
>> occurs
>> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
>> > > > >
>> > > > >
>> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
>> > > jira@apache.org
>> > > > > >wrote:
>> > > > >
>> > > > > > osapi (oslite) should support user mediated requests.
>> > > > > > -----------------------------------------------------
>> > > > > >
>> > > > > > Key: SHINDIG-1065
>> > > > > > URL:
>> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
>> > > > > > Project: Shindig
>> > > > > > Issue Type: New Feature
>> > > > > > Reporter: Sachin Shenoy
>> > > > > >
>> > > > > >
>> > > > > > According to osapi spec any request can be user mediated. (there
>> is
>> > > no
>> > > > > more
>> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
>> > requests.
>> > > > > >
>> > > > > > Changes:
>> > > > > > - Containers can via configuration let shindig JS know which
>> > requests
>> > > > it
>> > > > > > want to be user mediated.
>> > > > > > - Predefined hooks are used to pass the request to the container
>> > and
>> > > > get
>> > > > > > the response back.
>> > > > > > - A new type of request, osapi.newUiRequest is defined to handle
>> > user
>> > > > > > mediated case. Even though this is in global space, it need not
>> be
>> > > > > visible
>> > > > > > to the developer directly. Developer uses the osapi as today.
>> > > > > > - batch.js is modified to allow handling of user mediated
>> requests.
>> > > > > > - So that developer can know which request may get user
>> mediated,
>> > > every
>> > > > > > request exposes a boolean field userMediated (this is not part
>> of
>> > > > > standard
>> > > > > > but could be good to have something like this for future
>> version).
>> > > This
>> > > > > > would allow developers to write code like below,
>> > > > > >
>> > > > > > var r = osapi.activites.create();
>> > > > > > if (r.userMediated) {
>> > > > > > // skip creating activity, as I don't want to bug the user.
>> > > > > > } else {
>> > > > > > r.execute();
>> > > > > > }
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > This message is automatically generated by JIRA.
>> > > > > > -
>> > > > > > You can reply to this email to add a comment to the issue
>> online.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
Hi Louis,
Could you please look into this change?
Thanks,
Sachin
On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <sa...@google.com> wrote:
> I have uploaded a new patch which does the suggested introspection.
> Sachin
>
>
> On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
>
>> All of these are valid approaches. We already introspect the
>> server-endpoint
>> for the JSON-RPC methods which gives a nice level of decoupling between
>> gadget server and API server. Having the same in the client is certainly
>> useful for gadget renderers that must interoperate with many containers.
>>
>> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
>> wrote:
>>
>> > I would love to have a decoupled deployment. One thing that can be done
>> is
>> > to do server side introspection. Let the gadget renderer introspect the
>> > mediated methods much like the normal methods via "mediatedMethods"
>> call?
>> > Sachin
>> >
>> > PS.
>> > Going a step further (may be a bit too further), an endpoint could
>> support
>> > a
>> > "getConfig" method. Gadget server could query that to get the json
>> config
>> > that would be merged with the static configuration before inserting it
>> into
>> > the iframe.
>> >
>> >
>> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>> >
>> > > In many ways the binding mechanism is an implementation detail. The
>> > > information could just as easily go in container config. The main
>> point
>> > is
>> > > that the osapi code treats gadgets-rpc as just a transport for
>> JSON-RPC
>> > > style calls and the interfaces, packaging and format of the methods
>> > aligns
>> > > closely with that for the dat-backed APIs. One advantage of following
>> > this
>> > > design methodology is that it would easily allow a container to
>> implement
>> > a
>> > > fully mediated API. The concerns with the late binding that you list
>> are
>> > > valid and should be weighed against the advantages of a decoupled
>> > > deployment
>> > > process between the container and the gadget server.
>> > >
>> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
>> > > wrote:
>> > >
>> > > > This would change the way we get the list of mediated methods but I
>> > guess
>> > > > other stuff remains same?
>> > > > Currently we are getting this list via configuration, but you
>> suggest
>> > it
>> > > is
>> > > > better to get it by introspection with the container. With client
>> side
>> > > > introspection I see these issues,
>> > > >
>> > > > 1. Race condition. I think this can be solvable, by delaying the
>> actual
>> > > > call
>> > > > of gadgets.util.runOnLoadHandlers.
>> > > > 2. We force the containers to implement the introspection method, a
>> > > > container failing to do so would cause bad things (we would wait
>> > > > indefinitely for the callback).
>> > > > 3. Any delay caused by the introspection(?)
>> > > >
>> > > > Sachin
>> > > >
>> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
>> wrote:
>> > > >
>> > > > > Rather than doing this we should do something akin to what we've
>> done
>> > > for
>> > > > > the JSON-RPC introspection support in osapi. i.e
>> > > > >
>> > > > > 1. osapi makes a gadgets.rpc to container asking for the supported
>> > > > methods.
>> > > > > 2. Container returns that list in the format used for JSON-RPC's
>> > > > > system.listMethod
>> > > > > 3. osapi binds the returned services in the same manner it
>> supports
>> > it
>> > > > for
>> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
>> occurs
>> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
>> > > > >
>> > > > >
>> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
>> > > jira@apache.org
>> > > > > >wrote:
>> > > > >
>> > > > > > osapi (oslite) should support user mediated requests.
>> > > > > > -----------------------------------------------------
>> > > > > >
>> > > > > > Key: SHINDIG-1065
>> > > > > > URL:
>> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
>> > > > > > Project: Shindig
>> > > > > > Issue Type: New Feature
>> > > > > > Reporter: Sachin Shenoy
>> > > > > >
>> > > > > >
>> > > > > > According to osapi spec any request can be user mediated. (there
>> is
>> > > no
>> > > > > more
>> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
>> > requests.
>> > > > > >
>> > > > > > Changes:
>> > > > > > - Containers can via configuration let shindig JS know which
>> > requests
>> > > > it
>> > > > > > want to be user mediated.
>> > > > > > - Predefined hooks are used to pass the request to the container
>> > and
>> > > > get
>> > > > > > the response back.
>> > > > > > - A new type of request, osapi.newUiRequest is defined to handle
>> > user
>> > > > > > mediated case. Even though this is in global space, it need not
>> be
>> > > > > visible
>> > > > > > to the developer directly. Developer uses the osapi as today.
>> > > > > > - batch.js is modified to allow handling of user mediated
>> requests.
>> > > > > > - So that developer can know which request may get user
>> mediated,
>> > > every
>> > > > > > request exposes a boolean field userMediated (this is not part
>> of
>> > > > > standard
>> > > > > > but could be good to have something like this for future
>> version).
>> > > This
>> > > > > > would allow developers to write code like below,
>> > > > > >
>> > > > > > var r = osapi.activites.create();
>> > > > > > if (r.userMediated) {
>> > > > > > // skip creating activity, as I don't want to bug the user.
>> > > > > > } else {
>> > > > > > r.execute();
>> > > > > > }
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > This message is automatically generated by JIRA.
>> > > > > > -
>> > > > > > You can reply to this email to add a comment to the issue
>> online.
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
I have uploaded a new patch which does the suggested introspection.
Sachin
On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
> All of these are valid approaches. We already introspect the
> server-endpoint
> for the JSON-RPC methods which gives a nice level of decoupling between
> gadget server and API server. Having the same in the client is certainly
> useful for gadget renderers that must interoperate with many containers.
>
> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
> wrote:
>
> > I would love to have a decoupled deployment. One thing that can be done
> is
> > to do server side introspection. Let the gadget renderer introspect the
> > mediated methods much like the normal methods via "mediatedMethods" call?
> > Sachin
> >
> > PS.
> > Going a step further (may be a bit too further), an endpoint could
> support
> > a
> > "getConfig" method. Gadget server could query that to get the json config
> > that would be merged with the static configuration before inserting it
> into
> > the iframe.
> >
> >
> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
> >
> > > In many ways the binding mechanism is an implementation detail. The
> > > information could just as easily go in container config. The main point
> > is
> > > that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> > > style calls and the interfaces, packaging and format of the methods
> > aligns
> > > closely with that for the dat-backed APIs. One advantage of following
> > this
> > > design methodology is that it would easily allow a container to
> implement
> > a
> > > fully mediated API. The concerns with the late binding that you list
> are
> > > valid and should be weighed against the advantages of a decoupled
> > > deployment
> > > process between the container and the gadget server.
> > >
> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> > > wrote:
> > >
> > > > This would change the way we get the list of mediated methods but I
> > guess
> > > > other stuff remains same?
> > > > Currently we are getting this list via configuration, but you suggest
> > it
> > > is
> > > > better to get it by introspection with the container. With client
> side
> > > > introspection I see these issues,
> > > >
> > > > 1. Race condition. I think this can be solvable, by delaying the
> actual
> > > > call
> > > > of gadgets.util.runOnLoadHandlers.
> > > > 2. We force the containers to implement the introspection method, a
> > > > container failing to do so would cause bad things (we would wait
> > > > indefinitely for the callback).
> > > > 3. Any delay caused by the introspection(?)
> > > >
> > > > Sachin
> > > >
> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
> wrote:
> > > >
> > > > > Rather than doing this we should do something akin to what we've
> done
> > > for
> > > > > the JSON-RPC introspection support in osapi. i.e
> > > > >
> > > > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > > > methods.
> > > > > 2. Container returns that list in the format used for JSON-RPC's
> > > > > system.listMethod
> > > > > 3. osapi binds the returned services in the same manner it supports
> > it
> > > > for
> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
> occurs
> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > > > >
> > > > >
> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> > > jira@apache.org
> > > > > >wrote:
> > > > >
> > > > > > osapi (oslite) should support user mediated requests.
> > > > > > -----------------------------------------------------
> > > > > >
> > > > > > Key: SHINDIG-1065
> > > > > > URL:
> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > > > Project: Shindig
> > > > > > Issue Type: New Feature
> > > > > > Reporter: Sachin Shenoy
> > > > > >
> > > > > >
> > > > > > According to osapi spec any request can be user mediated. (there
> is
> > > no
> > > > > more
> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
> > requests.
> > > > > >
> > > > > > Changes:
> > > > > > - Containers can via configuration let shindig JS know which
> > requests
> > > > it
> > > > > > want to be user mediated.
> > > > > > - Predefined hooks are used to pass the request to the container
> > and
> > > > get
> > > > > > the response back.
> > > > > > - A new type of request, osapi.newUiRequest is defined to handle
> > user
> > > > > > mediated case. Even though this is in global space, it need not
> be
> > > > > visible
> > > > > > to the developer directly. Developer uses the osapi as today.
> > > > > > - batch.js is modified to allow handling of user mediated
> requests.
> > > > > > - So that developer can know which request may get user mediated,
> > > every
> > > > > > request exposes a boolean field userMediated (this is not part of
> > > > > standard
> > > > > > but could be good to have something like this for future
> version).
> > > This
> > > > > > would allow developers to write code like below,
> > > > > >
> > > > > > var r = osapi.activites.create();
> > > > > > if (r.userMediated) {
> > > > > > // skip creating activity, as I don't want to bug the user.
> > > > > > } else {
> > > > > > r.execute();
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > This message is automatically generated by JIRA.
> > > > > > -
> > > > > > You can reply to this email to add a comment to the issue online.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
I have uploaded a new patch which does the suggested introspection.
Sachin
On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <lr...@google.com> wrote:
> All of these are valid approaches. We already introspect the
> server-endpoint
> for the JSON-RPC methods which gives a nice level of decoupling between
> gadget server and API server. Having the same in the client is certainly
> useful for gadget renderers that must interoperate with many containers.
>
> On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com>
> wrote:
>
> > I would love to have a decoupled deployment. One thing that can be done
> is
> > to do server side introspection. Let the gadget renderer introspect the
> > mediated methods much like the normal methods via "mediatedMethods" call?
> > Sachin
> >
> > PS.
> > Going a step further (may be a bit too further), an endpoint could
> support
> > a
> > "getConfig" method. Gadget server could query that to get the json config
> > that would be merged with the static configuration before inserting it
> into
> > the iframe.
> >
> >
> > On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
> >
> > > In many ways the binding mechanism is an implementation detail. The
> > > information could just as easily go in container config. The main point
> > is
> > > that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> > > style calls and the interfaces, packaging and format of the methods
> > aligns
> > > closely with that for the dat-backed APIs. One advantage of following
> > this
> > > design methodology is that it would easily allow a container to
> implement
> > a
> > > fully mediated API. The concerns with the late binding that you list
> are
> > > valid and should be weighed against the advantages of a decoupled
> > > deployment
> > > process between the container and the gadget server.
> > >
> > > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> > > wrote:
> > >
> > > > This would change the way we get the list of mediated methods but I
> > guess
> > > > other stuff remains same?
> > > > Currently we are getting this list via configuration, but you suggest
> > it
> > > is
> > > > better to get it by introspection with the container. With client
> side
> > > > introspection I see these issues,
> > > >
> > > > 1. Race condition. I think this can be solvable, by delaying the
> actual
> > > > call
> > > > of gadgets.util.runOnLoadHandlers.
> > > > 2. We force the containers to implement the introspection method, a
> > > > container failing to do so would cause bad things (we would wait
> > > > indefinitely for the callback).
> > > > 3. Any delay caused by the introspection(?)
> > > >
> > > > Sachin
> > > >
> > > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com>
> wrote:
> > > >
> > > > > Rather than doing this we should do something akin to what we've
> done
> > > for
> > > > > the JSON-RPC introspection support in osapi. i.e
> > > > >
> > > > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > > > methods.
> > > > > 2. Container returns that list in the format used for JSON-RPC's
> > > > > system.listMethod
> > > > > 3. osapi binds the returned services in the same manner it supports
> > it
> > > > for
> > > > > JSON-RPC, erasing the protocol backed ones if a name collision
> occurs
> > > > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > > > >
> > > > >
> > > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> > > jira@apache.org
> > > > > >wrote:
> > > > >
> > > > > > osapi (oslite) should support user mediated requests.
> > > > > > -----------------------------------------------------
> > > > > >
> > > > > > Key: SHINDIG-1065
> > > > > > URL:
> > > > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > > > Project: Shindig
> > > > > > Issue Type: New Feature
> > > > > > Reporter: Sachin Shenoy
> > > > > >
> > > > > >
> > > > > > According to osapi spec any request can be user mediated. (there
> is
> > > no
> > > > > more
> > > > > > osapi.ui.*). Shindig to support mechanism for user mediated
> > requests.
> > > > > >
> > > > > > Changes:
> > > > > > - Containers can via configuration let shindig JS know which
> > requests
> > > > it
> > > > > > want to be user mediated.
> > > > > > - Predefined hooks are used to pass the request to the container
> > and
> > > > get
> > > > > > the response back.
> > > > > > - A new type of request, osapi.newUiRequest is defined to handle
> > user
> > > > > > mediated case. Even though this is in global space, it need not
> be
> > > > > visible
> > > > > > to the developer directly. Developer uses the osapi as today.
> > > > > > - batch.js is modified to allow handling of user mediated
> requests.
> > > > > > - So that developer can know which request may get user mediated,
> > > every
> > > > > > request exposes a boolean field userMediated (this is not part of
> > > > > standard
> > > > > > but could be good to have something like this for future
> version).
> > > This
> > > > > > would allow developers to write code like below,
> > > > > >
> > > > > > var r = osapi.activites.create();
> > > > > > if (r.userMediated) {
> > > > > > // skip creating activity, as I don't want to bug the user.
> > > > > > } else {
> > > > > > r.execute();
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > This message is automatically generated by JIRA.
> > > > > > -
> > > > > > You can reply to this email to add a comment to the issue online.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Louis Ryan <lr...@google.com>.
All of these are valid approaches. We already introspect the server-endpoint
for the JSON-RPC methods which gives a nice level of decoupling between
gadget server and API server. Having the same in the client is certainly
useful for gadget renderers that must interoperate with many containers.
On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com> wrote:
> I would love to have a decoupled deployment. One thing that can be done is
> to do server side introspection. Let the gadget renderer introspect the
> mediated methods much like the normal methods via "mediatedMethods" call?
> Sachin
>
> PS.
> Going a step further (may be a bit too further), an endpoint could support
> a
> "getConfig" method. Gadget server could query that to get the json config
> that would be merged with the static configuration before inserting it into
> the iframe.
>
>
> On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>
> > In many ways the binding mechanism is an implementation detail. The
> > information could just as easily go in container config. The main point
> is
> > that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> > style calls and the interfaces, packaging and format of the methods
> aligns
> > closely with that for the dat-backed APIs. One advantage of following
> this
> > design methodology is that it would easily allow a container to implement
> a
> > fully mediated API. The concerns with the late binding that you list are
> > valid and should be weighed against the advantages of a decoupled
> > deployment
> > process between the container and the gadget server.
> >
> > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> > wrote:
> >
> > > This would change the way we get the list of mediated methods but I
> guess
> > > other stuff remains same?
> > > Currently we are getting this list via configuration, but you suggest
> it
> > is
> > > better to get it by introspection with the container. With client side
> > > introspection I see these issues,
> > >
> > > 1. Race condition. I think this can be solvable, by delaying the actual
> > > call
> > > of gadgets.util.runOnLoadHandlers.
> > > 2. We force the containers to implement the introspection method, a
> > > container failing to do so would cause bad things (we would wait
> > > indefinitely for the callback).
> > > 3. Any delay caused by the introspection(?)
> > >
> > > Sachin
> > >
> > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> > >
> > > > Rather than doing this we should do something akin to what we've done
> > for
> > > > the JSON-RPC introspection support in osapi. i.e
> > > >
> > > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > > methods.
> > > > 2. Container returns that list in the format used for JSON-RPC's
> > > > system.listMethod
> > > > 3. osapi binds the returned services in the same manner it supports
> it
> > > for
> > > > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > > >
> > > >
> > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> > jira@apache.org
> > > > >wrote:
> > > >
> > > > > osapi (oslite) should support user mediated requests.
> > > > > -----------------------------------------------------
> > > > >
> > > > > Key: SHINDIG-1065
> > > > > URL:
> > > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > > Project: Shindig
> > > > > Issue Type: New Feature
> > > > > Reporter: Sachin Shenoy
> > > > >
> > > > >
> > > > > According to osapi spec any request can be user mediated. (there is
> > no
> > > > more
> > > > > osapi.ui.*). Shindig to support mechanism for user mediated
> requests.
> > > > >
> > > > > Changes:
> > > > > - Containers can via configuration let shindig JS know which
> requests
> > > it
> > > > > want to be user mediated.
> > > > > - Predefined hooks are used to pass the request to the container
> and
> > > get
> > > > > the response back.
> > > > > - A new type of request, osapi.newUiRequest is defined to handle
> user
> > > > > mediated case. Even though this is in global space, it need not be
> > > > visible
> > > > > to the developer directly. Developer uses the osapi as today.
> > > > > - batch.js is modified to allow handling of user mediated requests.
> > > > > - So that developer can know which request may get user mediated,
> > every
> > > > > request exposes a boolean field userMediated (this is not part of
> > > > standard
> > > > > but could be good to have something like this for future version).
> > This
> > > > > would allow developers to write code like below,
> > > > >
> > > > > var r = osapi.activites.create();
> > > > > if (r.userMediated) {
> > > > > // skip creating activity, as I don't want to bug the user.
> > > > > } else {
> > > > > r.execute();
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > This message is automatically generated by JIRA.
> > > > > -
> > > > > You can reply to this email to add a comment to the issue online.
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Louis Ryan <lr...@google.com>.
All of these are valid approaches. We already introspect the server-endpoint
for the JSON-RPC methods which gives a nice level of decoupling between
gadget server and API server. Having the same in the client is certainly
useful for gadget renderers that must interoperate with many containers.
On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <sa...@google.com> wrote:
> I would love to have a decoupled deployment. One thing that can be done is
> to do server side introspection. Let the gadget renderer introspect the
> mediated methods much like the normal methods via "mediatedMethods" call?
> Sachin
>
> PS.
> Going a step further (may be a bit too further), an endpoint could support
> a
> "getConfig" method. Gadget server could query that to get the json config
> that would be merged with the static configuration before inserting it into
> the iframe.
>
>
> On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
>
> > In many ways the binding mechanism is an implementation detail. The
> > information could just as easily go in container config. The main point
> is
> > that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> > style calls and the interfaces, packaging and format of the methods
> aligns
> > closely with that for the dat-backed APIs. One advantage of following
> this
> > design methodology is that it would easily allow a container to implement
> a
> > fully mediated API. The concerns with the late binding that you list are
> > valid and should be weighed against the advantages of a decoupled
> > deployment
> > process between the container and the gadget server.
> >
> > On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> > wrote:
> >
> > > This would change the way we get the list of mediated methods but I
> guess
> > > other stuff remains same?
> > > Currently we are getting this list via configuration, but you suggest
> it
> > is
> > > better to get it by introspection with the container. With client side
> > > introspection I see these issues,
> > >
> > > 1. Race condition. I think this can be solvable, by delaying the actual
> > > call
> > > of gadgets.util.runOnLoadHandlers.
> > > 2. We force the containers to implement the introspection method, a
> > > container failing to do so would cause bad things (we would wait
> > > indefinitely for the callback).
> > > 3. Any delay caused by the introspection(?)
> > >
> > > Sachin
> > >
> > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> > >
> > > > Rather than doing this we should do something akin to what we've done
> > for
> > > > the JSON-RPC introspection support in osapi. i.e
> > > >
> > > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > > methods.
> > > > 2. Container returns that list in the format used for JSON-RPC's
> > > > system.listMethod
> > > > 3. osapi binds the returned services in the same manner it supports
> it
> > > for
> > > > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > > >
> > > >
> > > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> > jira@apache.org
> > > > >wrote:
> > > >
> > > > > osapi (oslite) should support user mediated requests.
> > > > > -----------------------------------------------------
> > > > >
> > > > > Key: SHINDIG-1065
> > > > > URL:
> > > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > > Project: Shindig
> > > > > Issue Type: New Feature
> > > > > Reporter: Sachin Shenoy
> > > > >
> > > > >
> > > > > According to osapi spec any request can be user mediated. (there is
> > no
> > > > more
> > > > > osapi.ui.*). Shindig to support mechanism for user mediated
> requests.
> > > > >
> > > > > Changes:
> > > > > - Containers can via configuration let shindig JS know which
> requests
> > > it
> > > > > want to be user mediated.
> > > > > - Predefined hooks are used to pass the request to the container
> and
> > > get
> > > > > the response back.
> > > > > - A new type of request, osapi.newUiRequest is defined to handle
> user
> > > > > mediated case. Even though this is in global space, it need not be
> > > > visible
> > > > > to the developer directly. Developer uses the osapi as today.
> > > > > - batch.js is modified to allow handling of user mediated requests.
> > > > > - So that developer can know which request may get user mediated,
> > every
> > > > > request exposes a boolean field userMediated (this is not part of
> > > > standard
> > > > > but could be good to have something like this for future version).
> > This
> > > > > would allow developers to write code like below,
> > > > >
> > > > > var r = osapi.activites.create();
> > > > > if (r.userMediated) {
> > > > > // skip creating activity, as I don't want to bug the user.
> > > > > } else {
> > > > > r.execute();
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > This message is automatically generated by JIRA.
> > > > > -
> > > > > You can reply to this email to add a comment to the issue online.
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
I would love to have a decoupled deployment. One thing that can be done is
to do server side introspection. Let the gadget renderer introspect the
mediated methods much like the normal methods via "mediatedMethods" call?
Sachin
PS.
Going a step further (may be a bit too further), an endpoint could support a
"getConfig" method. Gadget server could query that to get the json config
that would be merged with the static configuration before inserting it into
the iframe.
On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
> In many ways the binding mechanism is an implementation detail. The
> information could just as easily go in container config. The main point is
> that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> style calls and the interfaces, packaging and format of the methods aligns
> closely with that for the dat-backed APIs. One advantage of following this
> design methodology is that it would easily allow a container to implement a
> fully mediated API. The concerns with the late binding that you list are
> valid and should be weighed against the advantages of a decoupled
> deployment
> process between the container and the gadget server.
>
> On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> wrote:
>
> > This would change the way we get the list of mediated methods but I guess
> > other stuff remains same?
> > Currently we are getting this list via configuration, but you suggest it
> is
> > better to get it by introspection with the container. With client side
> > introspection I see these issues,
> >
> > 1. Race condition. I think this can be solvable, by delaying the actual
> > call
> > of gadgets.util.runOnLoadHandlers.
> > 2. We force the containers to implement the introspection method, a
> > container failing to do so would cause bad things (we would wait
> > indefinitely for the callback).
> > 3. Any delay caused by the introspection(?)
> >
> > Sachin
> >
> > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> >
> > > Rather than doing this we should do something akin to what we've done
> for
> > > the JSON-RPC introspection support in osapi. i.e
> > >
> > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > methods.
> > > 2. Container returns that list in the format used for JSON-RPC's
> > > system.listMethod
> > > 3. osapi binds the returned services in the same manner it supports it
> > for
> > > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > >
> > >
> > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> jira@apache.org
> > > >wrote:
> > >
> > > > osapi (oslite) should support user mediated requests.
> > > > -----------------------------------------------------
> > > >
> > > > Key: SHINDIG-1065
> > > > URL:
> > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > Project: Shindig
> > > > Issue Type: New Feature
> > > > Reporter: Sachin Shenoy
> > > >
> > > >
> > > > According to osapi spec any request can be user mediated. (there is
> no
> > > more
> > > > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> > > >
> > > > Changes:
> > > > - Containers can via configuration let shindig JS know which requests
> > it
> > > > want to be user mediated.
> > > > - Predefined hooks are used to pass the request to the container and
> > get
> > > > the response back.
> > > > - A new type of request, osapi.newUiRequest is defined to handle user
> > > > mediated case. Even though this is in global space, it need not be
> > > visible
> > > > to the developer directly. Developer uses the osapi as today.
> > > > - batch.js is modified to allow handling of user mediated requests.
> > > > - So that developer can know which request may get user mediated,
> every
> > > > request exposes a boolean field userMediated (this is not part of
> > > standard
> > > > but could be good to have something like this for future version).
> This
> > > > would allow developers to write code like below,
> > > >
> > > > var r = osapi.activites.create();
> > > > if (r.userMediated) {
> > > > // skip creating activity, as I don't want to bug the user.
> > > > } else {
> > > > r.execute();
> > > > }
> > > >
> > > >
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > You can reply to this email to add a comment to the issue online.
> > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
I would love to have a decoupled deployment. One thing that can be done is
to do server side introspection. Let the gadget renderer introspect the
mediated methods much like the normal methods via "mediatedMethods" call?
Sachin
PS.
Going a step further (may be a bit too further), an endpoint could support a
"getConfig" method. Gadget server could query that to get the json config
that would be merged with the static configuration before inserting it into
the iframe.
On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <lr...@google.com> wrote:
> In many ways the binding mechanism is an implementation detail. The
> information could just as easily go in container config. The main point is
> that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
> style calls and the interfaces, packaging and format of the methods aligns
> closely with that for the dat-backed APIs. One advantage of following this
> design methodology is that it would easily allow a container to implement a
> fully mediated API. The concerns with the late binding that you list are
> valid and should be weighed against the advantages of a decoupled
> deployment
> process between the container and the gadget server.
>
> On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com>
> wrote:
>
> > This would change the way we get the list of mediated methods but I guess
> > other stuff remains same?
> > Currently we are getting this list via configuration, but you suggest it
> is
> > better to get it by introspection with the container. With client side
> > introspection I see these issues,
> >
> > 1. Race condition. I think this can be solvable, by delaying the actual
> > call
> > of gadgets.util.runOnLoadHandlers.
> > 2. We force the containers to implement the introspection method, a
> > container failing to do so would cause bad things (we would wait
> > indefinitely for the callback).
> > 3. Any delay caused by the introspection(?)
> >
> > Sachin
> >
> > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> >
> > > Rather than doing this we should do something akin to what we've done
> for
> > > the JSON-RPC introspection support in osapi. i.e
> > >
> > > 1. osapi makes a gadgets.rpc to container asking for the supported
> > methods.
> > > 2. Container returns that list in the format used for JSON-RPC's
> > > system.listMethod
> > > 3. osapi binds the returned services in the same manner it supports it
> > for
> > > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > > 4. osapi will now dispatch those api calls of gadgets.rpc
> > >
> > >
> > > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <
> jira@apache.org
> > > >wrote:
> > >
> > > > osapi (oslite) should support user mediated requests.
> > > > -----------------------------------------------------
> > > >
> > > > Key: SHINDIG-1065
> > > > URL:
> > https://issues.apache.org/jira/browse/SHINDIG-1065
> > > > Project: Shindig
> > > > Issue Type: New Feature
> > > > Reporter: Sachin Shenoy
> > > >
> > > >
> > > > According to osapi spec any request can be user mediated. (there is
> no
> > > more
> > > > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> > > >
> > > > Changes:
> > > > - Containers can via configuration let shindig JS know which requests
> > it
> > > > want to be user mediated.
> > > > - Predefined hooks are used to pass the request to the container and
> > get
> > > > the response back.
> > > > - A new type of request, osapi.newUiRequest is defined to handle user
> > > > mediated case. Even though this is in global space, it need not be
> > > visible
> > > > to the developer directly. Developer uses the osapi as today.
> > > > - batch.js is modified to allow handling of user mediated requests.
> > > > - So that developer can know which request may get user mediated,
> every
> > > > request exposes a boolean field userMediated (this is not part of
> > > standard
> > > > but could be good to have something like this for future version).
> This
> > > > would allow developers to write code like below,
> > > >
> > > > var r = osapi.activites.create();
> > > > if (r.userMediated) {
> > > > // skip creating activity, as I don't want to bug the user.
> > > > } else {
> > > > r.execute();
> > > > }
> > > >
> > > >
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > You can reply to this email to add a comment to the issue online.
> > > >
> > > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Louis Ryan <lr...@google.com>.
In many ways the binding mechanism is an implementation detail. The
information could just as easily go in container config. The main point is
that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
style calls and the interfaces, packaging and format of the methods aligns
closely with that for the dat-backed APIs. One advantage of following this
design methodology is that it would easily allow a container to implement a
fully mediated API. The concerns with the late binding that you list are
valid and should be weighed against the advantages of a decoupled deployment
process between the container and the gadget server.
On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com> wrote:
> This would change the way we get the list of mediated methods but I guess
> other stuff remains same?
> Currently we are getting this list via configuration, but you suggest it is
> better to get it by introspection with the container. With client side
> introspection I see these issues,
>
> 1. Race condition. I think this can be solvable, by delaying the actual
> call
> of gadgets.util.runOnLoadHandlers.
> 2. We force the containers to implement the introspection method, a
> container failing to do so would cause bad things (we would wait
> indefinitely for the callback).
> 3. Any delay caused by the introspection(?)
>
> Sachin
>
> On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
>
> > Rather than doing this we should do something akin to what we've done for
> > the JSON-RPC introspection support in osapi. i.e
> >
> > 1. osapi makes a gadgets.rpc to container asking for the supported
> methods.
> > 2. Container returns that list in the format used for JSON-RPC's
> > system.listMethod
> > 3. osapi binds the returned services in the same manner it supports it
> for
> > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > 4. osapi will now dispatch those api calls of gadgets.rpc
> >
> >
> > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <jira@apache.org
> > >wrote:
> >
> > > osapi (oslite) should support user mediated requests.
> > > -----------------------------------------------------
> > >
> > > Key: SHINDIG-1065
> > > URL:
> https://issues.apache.org/jira/browse/SHINDIG-1065
> > > Project: Shindig
> > > Issue Type: New Feature
> > > Reporter: Sachin Shenoy
> > >
> > >
> > > According to osapi spec any request can be user mediated. (there is no
> > more
> > > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> > >
> > > Changes:
> > > - Containers can via configuration let shindig JS know which requests
> it
> > > want to be user mediated.
> > > - Predefined hooks are used to pass the request to the container and
> get
> > > the response back.
> > > - A new type of request, osapi.newUiRequest is defined to handle user
> > > mediated case. Even though this is in global space, it need not be
> > visible
> > > to the developer directly. Developer uses the osapi as today.
> > > - batch.js is modified to allow handling of user mediated requests.
> > > - So that developer can know which request may get user mediated, every
> > > request exposes a boolean field userMediated (this is not part of
> > standard
> > > but could be good to have something like this for future version). This
> > > would allow developers to write code like below,
> > >
> > > var r = osapi.activites.create();
> > > if (r.userMediated) {
> > > // skip creating activity, as I don't want to bug the user.
> > > } else {
> > > r.execute();
> > > }
> > >
> > >
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > You can reply to this email to add a comment to the issue online.
> > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Louis Ryan <lr...@google.com>.
In many ways the binding mechanism is an implementation detail. The
information could just as easily go in container config. The main point is
that the osapi code treats gadgets-rpc as just a transport for JSON-RPC
style calls and the interfaces, packaging and format of the methods aligns
closely with that for the dat-backed APIs. One advantage of following this
design methodology is that it would easily allow a container to implement a
fully mediated API. The concerns with the late binding that you list are
valid and should be weighed against the advantages of a decoupled deployment
process between the container and the gadget server.
On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <sa...@google.com> wrote:
> This would change the way we get the list of mediated methods but I guess
> other stuff remains same?
> Currently we are getting this list via configuration, but you suggest it is
> better to get it by introspection with the container. With client side
> introspection I see these issues,
>
> 1. Race condition. I think this can be solvable, by delaying the actual
> call
> of gadgets.util.runOnLoadHandlers.
> 2. We force the containers to implement the introspection method, a
> container failing to do so would cause bad things (we would wait
> indefinitely for the callback).
> 3. Any delay caused by the introspection(?)
>
> Sachin
>
> On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
>
> > Rather than doing this we should do something akin to what we've done for
> > the JSON-RPC introspection support in osapi. i.e
> >
> > 1. osapi makes a gadgets.rpc to container asking for the supported
> methods.
> > 2. Container returns that list in the format used for JSON-RPC's
> > system.listMethod
> > 3. osapi binds the returned services in the same manner it supports it
> for
> > JSON-RPC, erasing the protocol backed ones if a name collision occurs
> > 4. osapi will now dispatch those api calls of gadgets.rpc
> >
> >
> > On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <jira@apache.org
> > >wrote:
> >
> > > osapi (oslite) should support user mediated requests.
> > > -----------------------------------------------------
> > >
> > > Key: SHINDIG-1065
> > > URL:
> https://issues.apache.org/jira/browse/SHINDIG-1065
> > > Project: Shindig
> > > Issue Type: New Feature
> > > Reporter: Sachin Shenoy
> > >
> > >
> > > According to osapi spec any request can be user mediated. (there is no
> > more
> > > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> > >
> > > Changes:
> > > - Containers can via configuration let shindig JS know which requests
> it
> > > want to be user mediated.
> > > - Predefined hooks are used to pass the request to the container and
> get
> > > the response back.
> > > - A new type of request, osapi.newUiRequest is defined to handle user
> > > mediated case. Even though this is in global space, it need not be
> > visible
> > > to the developer directly. Developer uses the osapi as today.
> > > - batch.js is modified to allow handling of user mediated requests.
> > > - So that developer can know which request may get user mediated, every
> > > request exposes a boolean field userMediated (this is not part of
> > standard
> > > but could be good to have something like this for future version). This
> > > would allow developers to write code like below,
> > >
> > > var r = osapi.activites.create();
> > > if (r.userMediated) {
> > > // skip creating activity, as I don't want to bug the user.
> > > } else {
> > > r.execute();
> > > }
> > >
> > >
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > You can reply to this email to add a comment to the issue online.
> > >
> > >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
This would change the way we get the list of mediated methods but I guess
other stuff remains same?
Currently we are getting this list via configuration, but you suggest it is
better to get it by introspection with the container. With client side
introspection I see these issues,
1. Race condition. I think this can be solvable, by delaying the actual call
of gadgets.util.runOnLoadHandlers.
2. We force the containers to implement the introspection method, a
container failing to do so would cause bad things (we would wait
indefinitely for the callback).
3. Any delay caused by the introspection(?)
Sachin
On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> Rather than doing this we should do something akin to what we've done for
> the JSON-RPC introspection support in osapi. i.e
>
> 1. osapi makes a gadgets.rpc to container asking for the supported methods.
> 2. Container returns that list in the format used for JSON-RPC's
> system.listMethod
> 3. osapi binds the returned services in the same manner it supports it for
> JSON-RPC, erasing the protocol backed ones if a name collision occurs
> 4. osapi will now dispatch those api calls of gadgets.rpc
>
>
> On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <jira@apache.org
> >wrote:
>
> > osapi (oslite) should support user mediated requests.
> > -----------------------------------------------------
> >
> > Key: SHINDIG-1065
> > URL: https://issues.apache.org/jira/browse/SHINDIG-1065
> > Project: Shindig
> > Issue Type: New Feature
> > Reporter: Sachin Shenoy
> >
> >
> > According to osapi spec any request can be user mediated. (there is no
> more
> > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> >
> > Changes:
> > - Containers can via configuration let shindig JS know which requests it
> > want to be user mediated.
> > - Predefined hooks are used to pass the request to the container and get
> > the response back.
> > - A new type of request, osapi.newUiRequest is defined to handle user
> > mediated case. Even though this is in global space, it need not be
> visible
> > to the developer directly. Developer uses the osapi as today.
> > - batch.js is modified to allow handling of user mediated requests.
> > - So that developer can know which request may get user mediated, every
> > request exposes a boolean field userMediated (this is not part of
> standard
> > but could be good to have something like this for future version). This
> > would allow developers to write code like below,
> >
> > var r = osapi.activites.create();
> > if (r.userMediated) {
> > // skip creating activity, as I don't want to bug the user.
> > } else {
> > r.execute();
> > }
> >
> >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
Re: [jira] Created: (SHINDIG-1065) osapi (oslite) should support user
mediated requests.
Posted by Sachin Shenoy <sa...@google.com>.
This would change the way we get the list of mediated methods but I guess
other stuff remains same?
Currently we are getting this list via configuration, but you suggest it is
better to get it by introspection with the container. With client side
introspection I see these issues,
1. Race condition. I think this can be solvable, by delaying the actual call
of gadgets.util.runOnLoadHandlers.
2. We force the containers to implement the introspection method, a
container failing to do so would cause bad things (we would wait
indefinitely for the callback).
3. Any delay caused by the introspection(?)
Sachin
On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <lr...@google.com> wrote:
> Rather than doing this we should do something akin to what we've done for
> the JSON-RPC introspection support in osapi. i.e
>
> 1. osapi makes a gadgets.rpc to container asking for the supported methods.
> 2. Container returns that list in the format used for JSON-RPC's
> system.listMethod
> 3. osapi binds the returned services in the same manner it supports it for
> JSON-RPC, erasing the protocol backed ones if a name collision occurs
> 4. osapi will now dispatch those api calls of gadgets.rpc
>
>
> On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <jira@apache.org
> >wrote:
>
> > osapi (oslite) should support user mediated requests.
> > -----------------------------------------------------
> >
> > Key: SHINDIG-1065
> > URL: https://issues.apache.org/jira/browse/SHINDIG-1065
> > Project: Shindig
> > Issue Type: New Feature
> > Reporter: Sachin Shenoy
> >
> >
> > According to osapi spec any request can be user mediated. (there is no
> more
> > osapi.ui.*). Shindig to support mechanism for user mediated requests.
> >
> > Changes:
> > - Containers can via configuration let shindig JS know which requests it
> > want to be user mediated.
> > - Predefined hooks are used to pass the request to the container and get
> > the response back.
> > - A new type of request, osapi.newUiRequest is defined to handle user
> > mediated case. Even though this is in global space, it need not be
> visible
> > to the developer directly. Developer uses the osapi as today.
> > - batch.js is modified to allow handling of user mediated requests.
> > - So that developer can know which request may get user mediated, every
> > request exposes a boolean field userMediated (this is not part of
> standard
> > but could be good to have something like this for future version). This
> > would allow developers to write code like below,
> >
> > var r = osapi.activites.create();
> > if (r.userMediated) {
> > // skip creating activity, as I don't want to bug the user.
> > } else {
> > r.execute();
> > }
> >
> >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>