Ping. Sachin On Tue, May 26, 2009 at 11:15 PM, Sachin Shenoy <[email protected]> wrote:
> Hi Louis, > > Could you please look into this change? > > Thanks, > Sachin > > > On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <[email protected]>wrote: > >> I have uploaded a new patch which does the suggested introspection. >> Sachin >> >> >> On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>> > > 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 <[email protected]> >>> 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) < >>> > > [email protected] >>> > > > > >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. >>> > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> >> >> >
