Category Archives: Technology

Three tips for creating the “best ever” git command line!

As a recovering CVS user turned svn master, and now an aspiring git ninja, I am sharing some of the tips and tricks to make my git environment as enjoyable and effective as possible.  First a little tough love: if you are not using the git command line, then just move along… these aren’t the droids you’re looking for.  But seriously, if you want to learn how to use git better you MUST MUST MUST use the command line. But if you are going to use a GUI, then PLEASE do us all a favor and avoid Github for Mac and instead get a tool like Tower.

So if you are still reading you are in the right place! 🙂

Tip #1:  If you are not using bash-completion, start now! Seriously! Stop reading this post and go install bash-completion immediately! This is the single biggest time saver; period. It provides completions via a deep knowledge of common tools such as git, ssh, jar, java, man, etc. For example:

  1. cd <your favorite git project>
  2. git checkout origin/<TAB><TAB>
  3. You will see all of the branches from the remote repo appear like magic!
  4. The git bash-completion knows about git commands, tags, branches, repositories, etc. So cool!
  5. Now try: git log –<TAB><TAB>
  6. It shows you all of the command line options for git log. With each git command having a wealth of options, this is a huge sanity saver.

Tip #2: Now that you have bash completing your git commands for you, how about we add some color to the results of git commands? Yes, seeing the output of a “git diff” colorized with additions in green and subtractions in red is, well after you get used to it, simply required.

Edit your ~/.gitconfig and add the following section:

[color]
  diff = auto
  status = auto
  branch = auto
  interactive = auto
  ui = auto

And while you are in there add this section to automatically run garbage collection for you!

[gc]
  auto = 1

Tip #3: Tired of typing “git status” to figure out if your branch is clean or dirty? Or if you need to push or pull to get caught up with a remote repo? The next git trick will really knock your socks off! Via the bash prompt, it displays the git branch you are currently on. If the branch is dirty the name of the branch is displayed in red. If the branch is clean the name is displayed in green. For example:

…clean…

    [develop] /Develop/k2/rsmart/nakamura

…dirty…

    [develop] /Develop/k2/rsmart/nakamura

…ahead…

    [develop↑] /Develop/k2/rsmart/nakamura

…behind…

    [develop↓] /Develop/k2/rsmart/nakamura

…branches have diverged…

    [develop↕] /Develop/k2/rsmart/nakamura

Curious yet? Here are the arcane .bash_profile incantations to make this a reality:

c_cyan=`tput setaf 6`
c_red=`tput setaf 1`
c_green=`tput setaf 2`
c_sgr0=`tput sgr0`
parse_git_branch ()
{
    if git rev-parse --git-dir >/dev/null 2>&1
    then
        git_status="$(git status 2> /dev/null)"
        branch_pattern="^# On branch ([^${IFS}]*)"
        remote_pattern="# Your branch is (.*) of"
        diverge_pattern="# Your branch and (.*) have diverged"
        # add an else if or two here if you want to get more specific
        if [[ ${git_status} =~ ${remote_pattern} ]]; then
          if [[ ${BASH_REMATCH[1]} == "ahead" ]]; then
            remote="↑"
          elif [ ${BASH_REMATCH[1]} == "behind" ]]; then
            remote="↓"
          fi
        fi
        if [[ ${git_status} =~ ${diverge_pattern} ]]; then
          remote="↕"
        fi
        if [[ ${git_status} =~ ${branch_pattern} ]]; then
          branch=${BASH_REMATCH[1]}
          echo "${branch}${remote}"
        fi
    else
        return 0
    fi
}
branch_color ()
{
    if git rev-parse --git-dir >/dev/null 2>&1
    then
        git_status="$(git status 2> /dev/null)"
        color=""
        if [[ ${git_status} =~ "working directory clean" ]]; then
            color="${c_green}"
        else
            color=${c_red}
        fi
    else
        return 0
    fi
    echo -ne $color
}
export PS1='[\[$(branch_color)\]$(parse_git_branch)\[${c_sgr0}\]] \w\[${c_sgr0}\]$ '

With this information in hand, you should be well on your way to leveling-up your git ninja (ginja?) skills… 🙂

7 Comments

Filed under Technology, Tools

Hybrid: State of the Union

It has been a while since I have written about the Sakai Hybrid integration between CLE and OAE. With some visioning help from David Goodrum and some technical wizardry by Steve Githens, we managed to hit a major milestone leading up to the Sakai 2011 Conference. This milestone allowed us to perform a live demonstration of a couple of important use cases:

  1. Using the Sakai OAE portal to launch directly into a CLE site experience.
  2. Being able to pull individual CLE tools into OAE content pages as widgets.

The first use case is important if you want a single URL for your users to enter their LMS experience regardless of whether they are primarily CLE or OAE users. This mode will allow CLE users to ease into an OAE experience while maintaining a very familiar CLE user interface.  In other words, think of it as a new portal for CLE that has some new capabilities.

The second use case is targeted more at users who are adopting the complete OAE user experience, but still need access to some functionality provided by the CLE (think of Assignments, Gradebook, and Tests & Quizzes as examples). This capability allows one to pull one or more CLE tools into an OAE content page as widgets. The other interesting thing is that the underlying technology behind this tool integration is what is known as IMS Learning Tools Interoperability or LTI for short.  This technology will not only allow OAE to pull in external CLE tools, it will also allow OAE to pull in other LTI enabled tools or applications (think EtherPad, WordPress, Moodle, or Blackboard as examples).

David Goodrum introduces the Hybrid concept and value proposition:

Lance Speelmon demonstrates Hybrid use cases:

Steve Githens expands on possibilities:

Finally we wrap up with some Q&A:

1 Comment

Filed under Education, Sakai, Technology

Sakai Conference – Call for proposals

I am a member of the program committee for the upcoming Sakai conference in Los Angeles on June 14 – 16. I would like to invite you to join us in Los Angeles, and to solicit your help in both defining and creating the agenda.

Many of the conference attendees will be using or evaluating Sakai, but we hope to include broader content that speaks to effective systems and practices with technology-enhanced teaching, learning and research.

We have created a Request for Presentation Suggestions to allow broader participation in suggesting the conference content and presentations that would be most helpful. Please take a moment to share your suggestions about the sessions and content that would be most beneficial. This information can be submitted and reviewed immediately.

We have also posted the Call for Presentation Proposals requesting proposals for conference sessions, pre-conference workshops, birds of a feather topics, and showcases/tech demos. Please consider sharing your expertise in a formal session, or an informal discussion or demo.

I look forward to seeing you in June…

Best regards, Lance

Leave a comment

Filed under Education, Sakai, Technology

Sakai 3 Basic LTI… Now with more policies!

In an upcoming screencast, I will demonstrate a new Sakai 3 widget that hides all of the complexities of LTI settings from the end user. In the previous demonstration [1] you were able to see individual Sakai 2 tools living side-by-side with Sakai 3 widgets. You also saw a “sleight of hand” where I tried to paste in a 1) LTI URL, 2) LTI key, and 3) LTI shared secret without you noticing. While this made for decent “demo-ware”, it was an unreasonable set of expectations for a user who say simply wants to place a Sakai 2 Assignments tool onto a Sakai 3 page. My goal was to allow users to be able to place a Sakai 2 tool onto the page without having to know any settings.

To reach this next level of simplification, the required LTI settings would need to be supplied via administrative policies. Luckily, when I started developing the LTI service in Sakai 3, I anticipated such a need and built in some preliminary support for policies. Let’s start by taking a look at a policy, sakai.assignments.grades:

{
    "ltiurl":"http://localhost/imsblti/provider/sakai.assignment.grades",
    "ltiurl_lock":true,
    "ltikey_lock":true,
    "ltisecret_lock":true,
    "release_names":true,
    "release_names_lock":true,
    "frame_height":"100",
    "release_email":true,
    "release_email_lock":true,
    "release_principal_name":true,
    "release_principal_name_lock":true,
    "debug":false,
    "ltiKeys": {
      "ltikey":"12345",
      "ltisecret":"secret"
    }
}

All of the Basic LTI widget settings can be configured via such a policy. There are two aspects to each setting, 1) the setting itself and 2) a lock. The interaction between the two works as follows:

  1. If no setting is configured, the Basic LTI widget will not be affected in any way.
  2. If a setting is supplied (i.e. with no lock) it will become a default value for the setting in the widget.
  3. If both the setting and the corresponding lock are set, then it becomes a policy which the end user cannot change.

Hopefully this is fairly straightforward. However, we have not talked about the key to a policy itself. That is to ask, what causes an associated policy to be read and applied during the launch of the Basic LTI widget? It is another setting on the widget itself: lti_virtual_tool_id. For example, setting lti_virtual_tool_id to a value of sakai.assignments.grades would cause the policy named /var/basiclti/sakai.assignments.grades to be applied. This will allow system implementers to create many virtual tools and policies for end users, either because they want to simplify their lives with some good default values, or they need to lock some of the settings down so that end users cannot modify them. Now before you get too excited, the bad news is that while all of this logic exists and has been tested in the backend service itself, it has not been added to the Basic LTI widget yet. You will be able to see these policies in action in an upcoming blog posting where I will demonstrate a new widget called “Sakai 2 Tools”. This new widget essentially has no settings as relies completely on the new administrative policies.

While we are on the subject of policies, there is another new feature in the Basic LTI service worth mentioning. This is a little abstract, but essentially LTI has a property context_id which has meaning similar to what Sakai might call a siteId. The Sakai 3 LTI service now has the ability to manually specify the context_id if needed. This will be important to the Sakai 2/3 Hybrid integration as we will want Sakai 3 to pass the siteId of the corresponding Sakai 2 site as the context_id. Let me explain in more detail:

  1. The Sakai 2 LTI provider normally operates in the following provisioning manner:
    1. If the user does not exist, create it.
    2. If the site (i.e. context_id) does not exist, create it.
    3. If the tool placement does not exist, create it.
  2. This is all well and good if you are integrating some untrusted third party system where you want all of the LTI stuff to be completely separate from your local stuff.
  3. But if you are integrating with something closer to home (i.e. more trusted), then you probably don’t want all of this provisioning occurring.
  4. For a given LTI key, the Sakai 2 LTI provider can be placed into a trusted mode where it will not perform any account, site, or tool provisioning.

It is this trusted mode of the Sakai 2 LTI provider that we are targeting with the ability to manually specify the LTI context_id in Sakai 3. To invoke this new capability, simply set the property lti_context_id on the Sakai 3 site node to the siteId of the Sakai 2 site. As you can see from the DefaultContextIdResolver, the value of lti_context_id will be used if it exists, otherwise, the fully path to the site node will be used as the context_id.

  public String resolveContextId(final Node node) throws RepositoryException {
    LOG.debug("resolveContextId(Node {})", node);
    if (node == null) {
      throw new IllegalArgumentException("Node cannot be null");
    }

    String contextId = null;
    if (node.hasProperty(key)) {
      // we have a special context_id we can use
      contextId = node.getProperty(key).getString();
    } else {
      // just use the path
      contextId = node.getPath();
    }
    return contextId;
  }

Until next time… L

[1] https://lancespeelmon.wordpress.com/2010/04/27/mix-and-match-sakai-2-and-sakai-3-tools/

Leave a comment

Filed under Sakai, Technology

X-SAKAI-TOKEN Authentication

I would like to draw your attention to some important changes in plumbing that is used in the hybrid integration between Sakai 2 and Sakai 3. First a little background… Previously, an authentication mechanism existed that allowed a system external to Sakai 2 to call into its services while not prompting the user for authentication and trusting the external system for the user’s identity. This has been used primarily to allow services in Sakai 3 to call services in Sakai 2 to retrieve, for example, lists of sites for which the user is a member. This kind of authentication should not be confused with a single-sign-on solution like CAS which casts the end user as the primary actor. This type of authentication mechanism is used for server-to-server communication, on behalf of the user, and is established by system administrators who declare trust relationships between the two systems. The basic flow looked like:

  1. End user requests data from Sakai 3 via HTTP GET method (e.g. to get a set of Sakai 2 sites for the current user).
  2. Request is proxied through Sakai 3.
  3. Sakai 3 adds a header to the request: X-SAKAI-TOKEN (includes username).
  4. Sakai 2 receives the request and examines the X-SAKAI-TOKEN.
  5. If the token is valid, establish a new session based on the username passed in the token, and process the request.

So let’s examine this a little closer… An example X-SAKAI-TOKEN looks like:

EEFSxb/coHvGM+69RhmfAlXJ9J0=;admin;1273688664630.

The token is comprised of three pieces of information separated by semicolons:

  1. EEFSxb/coHvGM+69RhmfAlXJ9J0= : A cryptographically secure hash of the message.
  2. admin : the username of the current user signed into the calling system, i.e. Sakai 3 in this example.
  3. 1273688664630 : Number of milliseconds since the epoch.

Inquiring minds are probably wondering why Sakai 2 would trust such a token… I mean, just because a web request shows up at your front door and has some official looking identification, does not mean we should allow them to run code as admin, right? Well that is where the next concept is introduced: the shared secret. Think of a shared secret as a password that both systems know. Sakai 3 used the shared secret to sign the message and since Sakai 2 also has the shared secret, it can verify the integrity of the message (i.e. ensuring the message has not been spoofed or tampered with in any way). Just to be clear, the message admin;1273688664630 is signed using the shared secret to create the hash EEFSxb/coHvGM+69RhmfAlXJ9J0= and then the hash is prepended to the message to create the token X-SAKAI-TOKEN: EEFSxb/coHvGM+69RhmfAlXJ9J0=;admin;1273688664630. Now Sakai 2 has everything it needs to verify the token. It can use it’s own shared secret to compute a hash of the message and verify it equals the hash that was passed in the token. If the hashes are equal, the message is valid and has not been tampered with in any way.

This capability is great for calling into Sakai 2. But lately I have started looking into how tools or widgets might start passing results between systems. Think about a student submitting an assignment to a Sakai 2 tool and having the results posted to a Gradebook running in Sakai 3.  We needed a way for Sakai 2 to be able to call into Sakai 3 using the X-SAKAI-TOKEN mechanism — and now we have it! Thanks to some help from Dr. Ian Boston, we have pulled the same authentication and identification techniques into Sakai 3; with some improvements of course:

  1. The HTTP header X-SAKAI-TOKEN has been renamed x-sakai-token (to save on your CAPS LOCK key).
  2. The signature has been upgraded to the latest and greatest standards: RFC 2104 compliant HMAC (Hash-based Message Authentication Code). Thanks to Carl Hall for adding this capability to Sakai 3.
  3. sakai.auth.trusted.server.enabled: setting to completely enable or disable this feature.
  4. sakai.auth.trusted.server.safe-hosts: setting to control which other servers we trust.
  5. The Sakai 2 implementation has also been updated with the same great improvements.

So now that we have some plumbing installed, I will return to considering results passing between Sakai 2 and Sakai 3. 🙂

PS – This same mechanism could be used with 3rd party systems if desired. Build a message, sign it with an HMAC, and stuff it into an HTTP x-sakai-token header and away you go… Think about it…

2 Comments

Filed under Java, Sakai, Technology

It’s Official: Sakai 3 has passed IMS Global’s LTI Certification

SakaiIMS Basic LTI Enabled

Just this week IMS made the official LTI certification test suite available and I am very pleased to announce that Sakai 3 has passed the certification tests with flying colors (i.e. 100%). Now we can display this cool “Basic LTI Enabled” image with our software. As of this writing, this distinction is shared only with Desire2Learn. You can keep up-to-date on the progress of LTI certifications by watching: Common Cartridge and Basic Learning Tools Interoperability Progress.

While the Sakai 3 LTI consumer has the potential to bring interesting 3rd party tools into the learning management system, our primary motivator for this work was to provide a way to surface Sakai 2 tools within Sakai 3. Using LTI to solve this problem has positioned us well and we are anxious to see other developers implement the LTI provider server-side interface. Thanks to Dr. Chuck, Sakai 2.7 will ship with both an LTI consumer and LTI provider!

For more information on Basic LTI, see: Basic Learning Tools Interoperability. If you are interested in the certification test suite, see: Sakai 3 Basic LTI Widget Passing Certification Tests.

3 Comments

Filed under Education, Sakai, Technology

Mix and match Sakai 2 and Sakai 3 tools

I am very pleased to be able to share an important update with the Sakai community regarding the ongoing efforts to create a flexible migration path from Sakai 2 to Sakai 3. I have been blogging recently [1] [2] about the development of a new Basic LTI widget for Sakai 3. This effort builds on the existing capabilities [3] of Sakai 3 which allows you to expose entire Sakai 2 sites within the Sakai 3 portal (i.e. with the addition of Sakai 3’s social networking features). The next step in this hybrid evolution was to add the capability to expose individual Sakai 2 tools within Sakai 3 sites. Furthermore, since we were developing this new capability as a Sakai 3 widget, this means that an end user could place multiple Sakai 2 tools onto a single Sakai 3 page (i.e. something not currently possible in Sakai 2). This may sound like a subtle distinction, but as you will see in the embedded video it is an important distinction as it helps to break Sakai 2 tools out of their silos. Instructors can now author pages with custom workflows that may include both Sakai 2 tools and Sakai 3 widgets!

Skip to 12:30 into the video if you want to skip the summary and background…

So now we are beginning to see a migration path for existing Sakai 2 implementations that looks like:

  1. Sakai 2 for course sites and Sakai 3 for project sites.
    1. Reduced risk deployment as there is no hard dependency on Sakai 3 being available. For example, if Sakai 3 were to go down, users could easily be directed back to the Sakai 2 portal.
    2. Sakai 3 portal may or may not be the default portal (i.e. implementers choice).
  2. Placement of Sakai 2 tools alongside Sakai 3 pages within a Sakai 3 site.
    1. Maintains more of a Sakai 2 user experience while allowing access to Sakai 3 capabilities within a single site.
    2. Provides a nice transition between #1 and #3 for those that find it valuable.
    3. Increases risk as now users are dependent on Sakai 3 remaining available.
  3. Mixing and matching Sakai 2 and Sakai 3 tools all on the same Sakai 3 page within a Sakai 3 site.
    1. Provides the greatest flexibility for course and project site design.
    2. Provides the most “native” Sakai 3 user experience while maintaining access to Sakai 2 functionality.
    3. Custom workflows may be created with both Sakai 2 tools and Sakai 3 widgets (i.e. even if you are just exposing Sakai 2 tools, this capability does not exist in Sakai 2).
    4. Maintains same risk profile as #2.
  4. Implementer’s selection…
    1. You do not need to think of the previous three deployment strategies as mutually exclusive or synchronous.
    2. You can make any or all of these solutions available to select user populations as you see fit at any time – all based on your local goals and comfort levels.

For example, one possible migration path may look like:

  1. Build confidence in Sakai 3 and keep risk at a minimal levels.
    1. Deploy Sakai 3 alongside Sakai 2 with hybrid mode enabled.
    2. Continue to use Sakai 2 for course sites.
    3. Begin to experiment with Sakai 3 portal and project sites.
    4. Make Sakai 3 portal available to select user populations to validate access to Sakai 3 social networking capabilities as well as access to Sakai 2 sites.
    5. Make Sakai 3 project sites available to select user populations.
  2. Make Sakai 3 portal the default portal for all users.
    1. Continue to use Sakai 2 for course sites.
    2. Expand use of Sakai 3 project sites.
    3. Develop fallback plan to mitigate dependency on Sakai 3 portal availability (i.e. you still have a fully functional Sakai 2 portal sitting there).
  3. Early adopters begin relying on Sakai 3 for course work.
  4. Full adoption of Sakai 3 for both course related and collaborative work.

There is a lot to consider here and to complicate matters further I predict not one migration will be identical to another. However, we hope that we have provided enough capabilities and flexibility to tailor each migration to fit the institution’s needs. Furthermore, there is a lot experience in our community in this area as almost all of us have made a similar migration in the past. This time things are a little different… This time we have direct control over both systems and can make the migration smoother.

Let’s continue the discussion in person at the annual conference. Christian Vuerings and I will be presenting on this topic in sessions titled “Integrating Sakai 2 and Sakai 3”. There will be two regular conference sessions and a technical demonstration. See you there! L

[1] http://bit.ly/9Brbdl
[2] http://bit.ly/bXVPVI
[3] http://bit.ly/bQKjlm

2 Comments

Filed under Education, Sakai, Technology

3rd Annual Ja-Sakai Conference Report

I was very pleased to join Lois Brooks at the 3rd Annual Ja-Sakai Conference (translated) hosted by Kumamoto University. The day prior to the conference Ryuichi Matsuba asked me to provide a presentation to his colleagues regarding how Indiana University’s software developments are organized and the various roles that team members play (slides link). I only was able to finish about one half of the presentation due to time constraints, but we did have some good discussion on related topics. I was very happy that Lois Brooks was able to participate in the discussion as she was able to field some of the questions I could not address directly. Thanks Lois!

Afterwards, Professor Makoto Miyazaki of Kumamoto University provided a sneak-peek of his Ja-Sakai presentation (kindly translated into English) detailing their ePortfolio development efforts which include:

  1. uPortal as the primary landing page for students. This provides the launch points for accessing both of their WebCT CE6 and Sakai 2.6 OSP instances.
  2. Student artifact submissions via the natural WebCT user interfaces.
  3. Automated batch transferal of the artifacts over to Sakai OSP Matrix for evaluation.
  4. A newly developed OSP tool which they call “Notifications” which is a type of dashboard that allows users to easily see pending work and links directly to the tools for completion.

This work is in support of their competency-based curriculum and will be presented at the 2010 Sakai Annual Conference in Denver, Colorado. For more information about Kumamoto University’s portfolio practices, see: http://www.gsis.kumamoto-u.ac.jp/en/gp.

The following day was the conference which started with some very kind opening remarks from Dr. Shin-ichi Abe, Vice President and Trustee Kumamoto University and Dr. Takeshi Mase, Nagoya University Graduate School of Information Science. After the opening remarks, Lois Brooks provided a very nice presentation titled “Technology and Learning”.

Following Lois’ presentation, I delivered “Sakai 3 and the next major web technologies”:

The remainder of the conference was conducted in Japanese, so Lois and I were kindly escorted by Tomomi Nagata and Yuuki Tsunemoto to a vegetarian lunch with twelve different types of tofu and a traditional Japanese tea ceremony at the local Samurai house. We then finished our afternoon at Kumamoto castle before returning to the conference center for the Ja-Sakai reception.  Some key takeaways for me from the reception:

  1. Nagoya University has officially announced their plans to migrate from WebCT to Sakai. The other universities are watching very closely.
  2. Kansai University, the largest private university in Japan, has adopted Sakai in partnership with a commercial entity (NS Solutions?). Their biggest issue with Sakai is the lack of custom workflows and were very excited to see the work coming out of Sakai 3 to help resolve this issue.
  3. Learning Java is presenting a problem to Sakai related development and lowering this barrier to entry is an important concern (e.g. think PHP developers). Much of Sakai development is occurring at the edge in Japanese Universities.
  4. Japan now has at least two commercial partners that are active in the Sakai space.
  5. Internationalization and localization of both Sakai the software and Sakai the website continue to be a hurdle for Japan.

I would like to convey many special thanks to our very kind and generous hosts from Kumamoto:

  • Dr. Ryuichi Matsuba
  • Dr. Shin-ichiro Kubota
  • Dr. Hiroshi Nakano
  • Ms. Tomomi Nagata
  • Ms. Yuuki Tsunemoto

PS – Ryuichi Matsuba made good on his promise to Sakai last year and unveiled two new Sakaigers at the conference this year. As you can imagine, the Japanese find the Sakaiger very endearing and kawaii!

PPS – I was a bit overwhelmed at how many QR Codes I saw in Japan – they are everywhere! Maybe what piqued my curiosity the most was the fact that the promotional materials for the conference (both print and web) contained QR codes. I thought I remembered Google starting to promote QR codes with Google maps, and that was indeed correct. I have now equipped my iPhone with a QR reader called QuickMark QR Code Reader and now I am able to read QR codes. I am using the QR Code Generator from the ZXing Project to generate QR codes. It looks like this technology is on the verge of adoption in the US and we should encourage it. Scanning a QR code with your phone sure beats typing a URL on a mobile device! I have also seen these displayed on business cards for a quick way to get a new contact into your address book. Very cool!

1 Comment

Filed under Education, Sakai, Technology

Status Update on Basic LTI Widget for Sakai 3

I am returning from a very productive trip to Japan to participate in the 3rd Annual Ja-Sakai Conference (which I will blog about shortly) – but I did want to provide a quick update on the progress I have made in developing the Sakai 3 Basic LTI consumer widget. In my previous post on this subject, Sakai 3 Basic LTI Widget Sprint, I outlined five action items:

  1. At least one screencast demonstrating the work to date – probably two. One showing the Basic LTI plumbing and passing of the LTI certification tests, and another showing Sakai2 tool placements in Sakai 3 sites.
  2. Some of the information in an LTI launch needs to be secured from end users. This will be a chance for me to learn more about access control in Sakai 3; see: KERN-591.
  3. The widget itself needs some renovation. I will likely copy the existing Remote Content widget and add the LTI settings.
  4. Create some virtual tools for existing Sakai 2 tools and add these to the out of box Sakai 3 experience.
  5. Work on the Sakai 2 Basic LTI provider servlet to make it more robust and support the specific Sakai 2/3 integration use cases.

So let me address these in order:

  1. I still  do not have any screencasts to show. I have made some significant progress on #3 so I am waiting to complete the UI overhaul before recording any screencasts.  Please be patient – I will have something to show very soon.
  2. I am pleased to report that the implementation of securing the appropriate LTI launch parameters (i.e. secret and password) has been completed. Each launch node which contains the settings, now will have a sub-node which can only be read or modified by an administrative account. This sub-node contains the LTI secret and password. The service then masks the complexity of the implementation with this sub-node so that the user interface contract did not change. So the end result is that if the LTI related nodes are found via search or some other mechanism, we no longer need to be concerned that any related sensitive data will be exposed to unprivileged users.
  3. I am also pleased to say that some significant progress has been made on a new user interface for this widget. Using the code from the Remote Content widget is proving to be quite useful and delivering a nice user experience. There has been some debate about whether the Preview capabilities from the Remote Content widget are appropriate for this use case, but assuming that adding these capabilities to the service are not too time consuming, I plan on including this feature for user testing if nothing else. I personally believe the preview capability is worth providing, but I am willing to be proved wrong.
  4. No progress has been made regarding virtual tool registrations. I believe this use case is not unique and will extend beyond the Basic LTI needs. I have been procrastinating on this topic until I have the time to engage in the discussion fully.  I expect that will be when the other action items are complete and we can apply focus to this one particular aspect of delivery.
  5. Some good progress has been made on the Sakai 2 BasicLTI provider. Through my work on BLTI-24, the provider is a bit more robust. And through Steve Swinsburg’s work on BLTI-31 we are now closer to having a tighter relationship between the Sakai 3 consumer and the Sakai 2 provider. This tighter trust relationship assumes the consumer is closely related to the provider (e.g. maybe within the same domain). I envision using this high trust configuration in conjunction with some auto-provisioning to keep a Sakai 2 and Sakai 3 system in synchronization, which we expect to be common for most hybrid implementations.

Leave a comment

Filed under Education, Sakai, Technology

Importing content from Sakai 2 into Sakai 3 (take 2)

Since returning from holiday, I have rejoined the matter of Importing content from Sakai 2 into Sakai 3. The first order of business was to refactor the XML parsing from SAX to StAX to deal with some potentially nasty classloader issues as suggested by Dr. Ian Boston. That went smoothly and I have to say that after using SAX, StAX is a much improved utility as you have more control and can pull events from the stream rather than having them pushed to you. This makes for more natural and supportable java code.

Next, there were some improvements that I wanted to make to the import code:

  1. Support for org.sakaiproject.content.types.urlResource types.
  2. Adding the metadata to the imported content.

After a week of plugging away on both fronts, some good progress has been made. First, a model conversion had to be considered for org.sakaiproject.content.types.urlResource types. In Sakai 2, these URL resources are simply presented in the UI as hyperlinks that open in a new window. Given the RESTful nature of Kernel2 (K2), I needed to decide how to best represent a hyperlink. My first thought was using the proxy capabilties of K2, but that presented some issues as proxy nodes must be stored under /var/proxy and the whole notion of proxying http requests has security implications – that is why K2 does not allow just anyone to create a proxy node.

I was probably too close to the problem and had trouble seeing the more obvious solution – why not use a http redirect? After noodling the problem for a while, the simpler solution finally entered my brain. After a bit of acking, I found that Sling already has support for redirects through its RedirectServlet which binds to sling:resourceType=sling:redirect. So then, it was just a fairly simple matter of creating a node, and setting the properties accordingly:

{
"sling:resourceType":"sling:redirect",
"sling:target":"http://sakaiproject.org/",
"sakai:id":"AirbV1U-",
"sakai:user":"admin",
"jcr:mimeType":"text/url",
"sakai:filename":"http://sakaiproject.org/",
"jcr:created":"Wed Oct 07 2009 13:53:00 GMT-0400",
"jcr:lastModified":"Wed Oct 07 2009 13:53:00 GMT-0400",
"jcr:primaryType":"nt:unstructured"
}

That was pretty much it for org.sakaiproject.content.types.urlResource types; the redirect works as expected. There are still a couple of things I would like to improve in this area:

  1. The node names for these urlResources need to be beautified. As the resource name comes through in the content.xml, it looks like “http:__sakaiproject.org_”. I have to strip out the “:” to avoid a JCR exception, so the node name currently looks like “http__sakaiproject.org_”. Ideally, it would match the display name, i.e. “http://sakaiproject.org/&#8221;. Perhaps some manner of escaping invalid characters might work, but further digging into the JCR is required. I am able to set “sakai:filename”:”http://sakaiproject.org/&#8221;, so maybe that is good enough; TBD.
  2. Since the jcr:primaryType==nt:unstructured, the URL is rendered as a folder when connected via WebDAV. It would be nice to get these URLs to render as a leaf node instead. I experimented with jcr:primaryType=nt:file, but ran into some roadblocks and backed off.

Regarding the mapping of metadata, that task proved to be mostly straightforward for the fields that have a one-to-one mapping. However, there are currently more supported metadata fields in Sakai2 than there are in Sakai3. There is no limitation on the number or type of metadata fields that can be stored in Sakai3, so I am considering just storing all of fields from Sakai2 just as a precaution and possible future-proofing. I am left wondering whether to store them with their current keys or to prepend something like “sakai2:” to all of the keys before storing them.

Looking towards the near term, I am likely to look into the following issues:

  1. All user uploaded content is currently stored in a BigStore under /_user/files. After discussing with Ian Boston, I will most likely refactor the import code to store its content in that BigStore as well. Although, the BigStore concept will likely be redesigned in the near future, so any work I do in this area will be nicely abstracted so that this behavior can be changed easily when and if BigStore is redesigned.
  2. With the move to BigStore, I will have to take a look at access control lists (ACLs) so the the user importing content will have the proper permissions.
  3. Next, I need to take a look at the contract between K2 and the “Content & Media” widget so that the imported content appears properly within the user interface.
  4. What about other content types that could be imported today? Content from the Forums tool may be a good candidate as K2 currently has support for threaded discussions. Chat might be another place to look… Other ideas?

Regarding the Sakai2+3 Hybrid mode, I have hopes to arrange a two day coding sprint with Dr. Chuck Severance and Noah Botimer to develop a BasicLTI consumer for Sakai3. This would allow us to easily place a Sakai2 tool within the context of a Sakai3 site. With any luck, we will get this sprint organized by the end of January. Until next time, L

1 Comment

Filed under Java, Sakai, Technology