[Building Sakai] Google Meets Sakai

[Duffy Gillman]

In review of the chatter on this list regarding Google Docs  
integration into Sakai I've realized I responded to Steven's message  
below but did so off-list.  I've been getting more questions about  
Google Docs and so want to try to disseminate information here where  
it will reach a broad audience. Answers are in-line below:

On Oct 7, 2010, at 11:54 AM, Steven Githens wrote:

> On 10/06/2010 11:58 AM, Nate Angell wrote:
>> Sakaigers:
>>
>> In case you missed it, I blogged about rSmart's new Google Docs
>> integration for Sakai, including a short demo screencast:
>> http://xolotl.org/blog/xolotl/sakai-meets-google
>>
>> As I state in the blog, rSmart expects to contribute the integration
>> to the Sakai community. We expect to release it in our upcoming 2.7.1
>> version, after which you'll be able to take it for a spin on mySakai:
>> http://mysakai.rsmart.com/
>>
>
> Neat.  Were you guys able to reuse any of the code from Sakai/GDocs  
> from
> the prototype we built a few years ago or did you need to start from
> scratch? [1]

I wish I'd known that was there. When I did my searching around this  
work didn't turn up. I'll take a look at it and see if there is  
anything to be gained by merging the efforts.

> Which actually raises a good question.  Being able to write resource
> plugins for Sakai 2.x is still an incredibly important thing to do,  
> and
> I'm curious what is the most straightforward way to do it these days
> that people have found, since you have to interop with wacked out  
> Sakai
> session variables and request filder forwarding and whatnot?

Straightforward... hahahahahahaha... ehem... *twitch twitch*

I'm a little bit shell-shocked by the experience. It took a lot of  
trial and error and was not smooth. More on that below.

>  Back then
> I was using simple RSF producers to it.  I'm wondering if it could be
> accomplished as well with some simple Jython/Rhino/Groovy type of
> servlets that tie into all that tool forwarding, so it could be easy  
> to
> write lots of resource plugins quickly.
>
> It was just too much scaffolding.  For instance, if it was really
> lightweight to do it, you could also do lots of BLTI stuff like  
> etherpad
> in resources.

Agreed. Once I got hip-deep into this I determined no one should ever  
have to do this sort of thing again. I developed some vague notions of  
a way to abstract away the complexity of dealing with the content  
management, entity, and resource tool stuff; but nothing has been  
pursued to the point that I'm sure it will work. That clearly would be  
a valuable addition. Time permitting, I'd be happy to talk about ideas  
on the front.

>
> A few questions:
>
> 1) Does it cache documents at all?  So if you change something on the
> Google end, and you reopen say, a PDF version of the document, you get
> the regenerated one.  It would be cool, if it always kept the last
> opened one available in the local Sakai storage so if you ever need to
> sever your ways with the google servers, or if there is an outage in
> gdocs [2] you still have at least something there.

No caching. The tool simply uses GData APIs to obtain a stream from  
Google and it passes it through to the user in response to the  
document request. The thought here was that this scheme offloads  
storage issues to Google and eliminates synchronization issues.

> 2) Can anyone other than the original author edit the documents  
> (does it
> use Sakai Role permissions for anything other than viewing?)  I guess
> does it do any sort of provisioning back and forth between Sakai and
> Google?  The API was horribly mismatched the last time I checked.

No provisioning back and forth. Mismatch is a problem as well as the  
lack of any guarantee that the Sakai users are known to Google and  
vice versa. Add also that role/authz provisioning would create another  
synchronization issue.

Anyway, I hope my answers help. Let me know if you have ideas on the  
"abstracting resource plugins" front.

Cheers,

   Duffy