You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by csev <cs...@umich.edu> on 2010/06/30 15:23:10 UTC

Question about calling server-side services from a feature

Hello,  

I am new to Shindig and doing some development exploring how to add a new feature to Shindig to support "gadgets for teaching and learning".  I am not proposing to add this feature - I want to simply build it as a prototype for now as an exercise to learn about Shindig.  

My feature will need some server-side code to do things like allow learning gadgets to store learning activity data, submit student assignments, etc etc.  The basic idea is to make it so that learning management system like Moodle, Sakai, Blackboard, etc can have a "slaved Shindig" so they can host learning gadgets that store data in the LMS system.

I have gotten to the point where I have built a new feature (the client JS, server JS, and feature.xml) and have it working.

I have also built a server side handler and have it properly registered in the server.  When I look at debug out from system.listMethods, I see my little service right in there along with the others:

method=system.listMethods
{result=[samplecontainer.update, activities.supportedFields, activities.update, activities.delete, activities.get, ims.getInfo, ...

I have trolled through the code of the various features, looking for a simple code sequence to call a server-side service from a feature and get a response.  I expect there is some simply and elegant utility bit I have not yet found.  Here is one of my many feeble attempts in my feature code:

  var args = [
    null, // go to parent
    "ims.getInfo", // service name
    null, // no callback
    gadgets.util.getUrlParameters().ifpctok ||
      gadgets.util.getUrlParameters().rpctoken || 0 // Legacy IFPC "security".
  ].concat(Array.prototype.slice.call(message));

  gadgets.rpc.call.apply(gadgets.rpc, args);

This gives me "Unknown RPC service: ims.getInfo".  I am sure that I am just missing some obvious pattern.

I appreciate any help - once I figure this out, I will gladly write up what it took to do this and put it on my blog for others to find and contribute as text for the part of the documentation that says "How to Add a New Feature: TODO" :)  

In the longer term, I also would be interested in thinking about ways to make a new feature a nice, self-contained JAR with nice registration points with the ability to add a feature by adding a Jar to a binary Shindig distro and perhaps one line to the web.xml to point Guice at the new feature to get it loaded and registered - but that is a ways off.  I need to walk before I fly.

Thanks in advance.

Charles Severance
University of Michigan
IMS Global Learning Consortium
www.dr-chuck.com

Re: Possible gadget parsing optimization

Posted by Jan Luehe <jl...@yahoo-inc.com>.
On 7/2/10 2:57 PM, Paul Lindner wrote:
> This might be tricky.
>
> You might split the base gadget data structures from the gadgets+view data structures.
>
> That way these things can stay immutable and be cached more easily.  Invalidation might be tricky though.  Watch out for race conditions.
>    

I was thinking that we could move some of the more expensive View 
initialization code from the View constructor into a separate init 
method, and delay execution of this init method until a View accessor 
method is called.

This change would be internal to View.java and would not require any 
changes to any of the data structures, but would have the effect of only 
initializing a gadget's current view.

Do you still see any potential issues with this?

Thanks,

Jan

>
> On Jul 2, 2010, at 10:33 AM, Jan Luehe wrote:
>
>    
>> Currently, when a GadgetSpec is constructed, all of a gadget's (possibly many) views are initialized (in the View constructor), which includes concatenating their Content sections and also parsing their PipelinedData tags.
>>
>> Preferably, we should initialize a view only when it is requested (that is, the gadget's "current" view).
>>
>> If there is an interest in this optimization, I will go ahead and prepare a patch.
>>
>> Thanks,
>>
>> Jan
>>
>>      
>

Re: Possible gadget parsing optimization

Posted by Paul Lindner <li...@inuus.com>.
This might be tricky.

You might split the base gadget data structures from the gadgets+view data structures.

That way these things can stay immutable and be cached more easily.  Invalidation might be tricky though.  Watch out for race conditions.


On Jul 2, 2010, at 10:33 AM, Jan Luehe wrote:

> Currently, when a GadgetSpec is constructed, all of a gadget's (possibly many) views are initialized (in the View constructor), which includes concatenating their Content sections and also parsing their PipelinedData tags.
> 
> Preferably, we should initialize a view only when it is requested (that is, the gadget's "current" view).
> 
> If there is an interest in this optimization, I will go ahead and prepare a patch.
> 
> Thanks,
> 
> Jan
>

Possible gadget parsing optimization

Posted by Jan Luehe <jl...@yahoo-inc.com>.
Currently, when a GadgetSpec is constructed, all of a gadget's (possibly 
many) views are initialized (in the View constructor), which includes 
concatenating their Content sections and also parsing their 
PipelinedData tags.

Preferably, we should initialize a view only when it is requested (that 
is, the gadget's "current" view).

If there is an interest in this optimization, I will go ahead and 
prepare a patch.

Thanks,

Jan

Re: Question about calling server-side services from a feature

Posted by John Hjelmstad <fa...@google.com>.
Hi Chuck:

I wouldn't worry about breaking the OpenSocial/gadgets boundary per se; the
terminology surrounding the two was long ago conflated. Whether you are or
aren't accessing user/"social" data, the specification for both are mixed as
the "Opensocial and Gadgets Spec."

This said, I appreciate your understanding that architecturally, these are
layered and as well that one can expose completely non-"social" data through
the "social-api" server and osapi mechanism.

Glad you're making progress; good luck on the rest!
John

On Wed, Jun 30, 2010 at 10:27 AM, csev <cs...@umich.edu> wrote:

> Tim,
>
> Thanks for your help.  Just knowing to stop staring at rpc was a big help.
>  :)
>
> This bit works and gets the client / server round trip to happen:
>
>  osapi.ims.getInfo().execute(function(result) {
>    alert('Welcome back');
>  });
>
> I figured it was simple :)
>
> But that makes me wonder if I am violating abstraction boundaries of have
> taken an incorrect approach.  I somewhat thought I was making a "gadget
> extension" not an "open social" extension - but perhaps I *am* writing an
> opensocial extension after all since I do want identity, friends, context,
> etc.
>
> I look in core.io and find the basic support to do XHR requests, but
> perhaps I really want to be operating at an open social level.  I will play
> some more to understand things better.
>
> For now, I am back off and running, and having fun figuring the code out.
>  Thanks.
>
> /Chuck
>
>
> On Jun 30, 2010, at 11:06 AM, Tim Wintle wrote:
>
> > On Wed, 2010-06-30 at 09:23 -0400, csev wrote:
> >> I have trolled through the code of the various features, looking for a
> >> simple code sequence to call a server-side service from a feature and
> >> get a response.  I expect there is some simply and elegant utility bit
> >> I have not yet found.
> >
> > <snip>
> >
> >> This gives me "Unknown RPC service: ims.getInfo".  I am sure that I am
> >> just missing some obvious pattern.
> >
> > gadgets.rpc is for calling client-side rpc services (javascript services
> > registered in the container hosting the gadget).
> >
> > you might be looking for the gadgets.io.* methods
> >
> >
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-Gadget.xml#rfc.section.12.2
> >
> > Tim Wintle
>

Re: Question about calling server-side services from a feature

Posted by csev <cs...@umich.edu>.
Tim,

Thanks for your help.  Just knowing to stop staring at rpc was a big help.  :)

This bit works and gets the client / server round trip to happen:

 osapi.ims.getInfo().execute(function(result) {
    alert('Welcome back');
  });

I figured it was simple :)

But that makes me wonder if I am violating abstraction boundaries of have taken an incorrect approach.  I somewhat thought I was making a "gadget extension" not an "open social" extension - but perhaps I *am* writing an opensocial extension after all since I do want identity, friends, context, etc.

I look in core.io and find the basic support to do XHR requests, but perhaps I really want to be operating at an open social level.  I will play some more to understand things better.

For now, I am back off and running, and having fun figuring the code out.  Thanks.

/Chuck


On Jun 30, 2010, at 11:06 AM, Tim Wintle wrote:

> On Wed, 2010-06-30 at 09:23 -0400, csev wrote:
>> I have trolled through the code of the various features, looking for a
>> simple code sequence to call a server-side service from a feature and
>> get a response.  I expect there is some simply and elegant utility bit
>> I have not yet found.
> 
> <snip>
> 
>> This gives me "Unknown RPC service: ims.getInfo".  I am sure that I am
>> just missing some obvious pattern. 
> 
> gadgets.rpc is for calling client-side rpc services (javascript services
> registered in the container hosting the gadget).
> 
> you might be looking for the gadgets.io.* methods
> 
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-Gadget.xml#rfc.section.12.2
> 
> Tim Wintle

Re: Question about calling server-side services from a feature

Posted by Tim Wintle <ti...@teamrubber.com>.
On Wed, 2010-06-30 at 09:23 -0400, csev wrote:
> I have trolled through the code of the various features, looking for a
> simple code sequence to call a server-side service from a feature and
> get a response.  I expect there is some simply and elegant utility bit
> I have not yet found.

<snip>

> This gives me "Unknown RPC service: ims.getInfo".  I am sure that I am
> just missing some obvious pattern. 

gadgets.rpc is for calling client-side rpc services (javascript services
registered in the container hosting the gadget).

you might be looking for the gadgets.io.* methods

http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-Gadget.xml#rfc.section.12.2

Tim Wintle