[Building Sakai] BasicLTI Post 2.7.0

[csev]

Switched to the dev list as the discussion is getting a bit broader.

On May 27, 2010, at 6:47 AM, Stephen Marquard wrote:

> Hi all,
> 
> I have a couple of BLTI questions:
> 
> 1. There is code that relates to LinkTool. BLTI will pass a session ID encrypted in the same way LinkTool does, reads some LinkTool config parameters and in fact will even create the linktool config files if missing (seed values for encryption). What's the purpose of this? If BLTI needs the same capabilities as LinkTool (e.g. ability for remote app to request a Sakai session), shouldn't it have parallel capabilities that aren't dependent on LinkTool (e.g. using the encrypted session id would require the linktool SakaiSigning.jws webservice)? It seems brittle and an unnecessary complication of the code.

The idea is to make BLTI an equivalent replacement to LinkTool so folks who need to call LinkTool inspired web services could switch to BasicLTI and more data, better launch security, and no need to call a web service to validate the launch to improve performance and work in environments that don't want to turn on web services.   A BLTI tool should be able to do the exact same things as a LinkTool as (I hope) BLTI sends the same info as LinkTool sends.

I factored the LinkTool config code out into a nice utility class - whereas in LinkTool it is just in the init code.  Whichever runs first will create the salt properly.  At some level, we could factor this to an independent location and use the same utility class in both places to reduce the brittleness.    While the tool was in contrib, I wanted to avoid patching "core" so I tolerated this "brittleness". 

If it oes not work as I expect, then it should be fixed.  If we want to refactor it for 2.8 to have one copy of the LinkTool code that is cool too - but someone other than me would need to test the refactored LinkTool because I never use LinkTool.

> 2. Is there any value to BLTI being a portlet rather than a regular tool? If so under what circumstances would its portlet nature be valuable?

Portlets eliminate the tool frame - since Basic LTI itself requires an iFrame, I did not want an iFrame inside of an iFrame, potentially requiring two layers of "auto-sizing" and possibly two layers of scrollbars.

A some point, I started a project to replace the web tool with a Portlet version of the web tool to accomplish the removal of the second iframe and the general ugliness around two levels of iframe and the fact the the web tool wven when popped up puts an iframe within an iframe for the sole purpose to allow config (yuck).   I have (somewhere) nearly a nearly complete replacement for the web tool (web2 as it were).   I stopped developing on it because I knew there would need to be a lot of discussion about all the trick ways the web tool has been hacked and make sure that all of them continued to work before I could introduce web2.

I honestly think that Portlets are a better way to build tools in general because the lack of iframe - but we are way past that decision in Sakai 2.x :)

/Chuck