Please forward this message and/or print-and-post as appropriate.
OhioLINK Seeks Student Applications for Google Summer of Code
Student applications for the Google Summer of Code program are
being accepted starting on May 1st. In preparation for that date,
OhioLINK has finished up its list of ideas and other supporting
documentation. We welcome student applications seeking to further the
development of information technology in academic libraries in Ohio and
around the world. Questions about the program? Take a look at Google's participant FAQ.
Questions about the suggested projects or about OhioLINK? Contact Peter Murray.
This is the list of project ideas so far. Please take a look at the project ideas
page on the DRC-Dev wiki for updates.
JPIP Streaming Disseminator
JPIP is Part 9
of the JPEG 2000
specification and is used to stream image codestream blocks to a client
on demand. For instance, a JPIP client on a desktop may ask for a
certain quality level and resolution of a region of an image. Using the
JPIP protocol, the client makes such requests to a server and the
server responds with only the image codestream blocks needed by the
client. This saves the overhead of transmitting the entire image file
when, say, only a thumbnail version is required.
Fedora is the "Flexible Extensible Digital Object Repository
Architecture", an open source digital object repository created by
Cornell University and the University of Virginia. A key aspect of the
Fedora software is its use of "disseminators" to create derivatives
on-demand of datastreams stored in the digital object package.
For this project, the idea is have a JPIP client (outside the scope of
this project) request an image of a specified quality/resolution/clip
and have the FEDORA/JPIP plug-in retrieve and copy out only the
precincts/packets directly from an archived master plus metadata needed
for the quality specified. In theory, no image processing on the server
would be required.
Extensions to this disseminator to enforce XACML policies (a capability
built into Fedora now) to determine maximum quality available for
different end-user types are desired.
You can imagine how useful a plugin like this would be. There would be
no need to retrieve the full master and create derivatives, nor
stockpile limited sets of derivatives outside of the archive against
possible end-user requests.
JPIP Image Viewer Applet
In tandem with the "JPIP Streaming Disseminator for Fedora" proposed
above is a JPIP browser applet. Most browser-based JPEG 2000 plugins
must be licensed from a software vendor and are not freely
distributable. In order to deliver imagery in JPEG 2000 format to
standard browsers, one must use a server-side transformations of the
JPEG 2000 codestreams into JPEG chunks that are delivered to the
browser. Based on the user's requests -- to pan, zoom, select a new
region of the image, etc. -- the browser must make a new request to the
server and the server render a new JPEG image for the browser. This is
an inefficient use of server resources and forces a less-than-desirable
responsiveness in the user interface.
In addition, these general-purpose viewers do not have features, such
as the display of metadata boxes, important to the application of JPEG
2000 in the museum, library and archival communities. What is desired
instead is a cross-platform (Java, flash, etc.) JPIP (streaming
JPEG 2000) viewer with these characteristics:
- web distributable, browser compliant, and broadly available
- ability to see the entire image and parts of an image with
acceptable performance over narrow-band connections
- manipulation functionality such as pan, zoom, rotate, invert, and
- ability to put the image in its context with metadata that is
either textual or in other media and can be made visible or suppressed
- dynamic retrieve the contextual information
- meets identified image quality requirements
- transformative tools (i.e. the ability to save the image into a
file format selected by the user)
Video Snapshot Tool
OhioLINK's content repository includes approximately 1,900 educational
videos on various topics. These videos range in length from 20 minutes
to 80 minutes, and minimal description is provided for the video
content. We would like to add a capability for users browsing the
collection to see "snapshots" of what the video contains. In its
simplest form, the tool would pull out frames from the video in
equally-spaced increments. In a more advanced form, the tool would scan
the video looking for characteristics of scene changes and pull out the
nth frame after the scene change. These frames would be stored
as individual images -- or possibly as index pointers into the video
itself -- in the object containing the video, and subsequently
displayed to users on the full-record view of the video.
Conversion Using a Computational Grid
The 1,900 educational videos in OhioLINK's content repository are in
Realmedia format. We would like to have a tool that converts the
Realmedia format into a new streaming format. This tool would also be
used to convert incoming MPEG-2 videos into a streaming video format.
Since OhioLINK does not have a computational grid set up now, the
proposal must include assistance in setting up that grid (so long as
the grid setup is not a substantial part of the proposal -- it is the
Summer of Code after all). Note that some background research
has been done using the University
of Wisconsin Condor cluster software.
Motion JPEG2000 to Flash Video Transcoder / Viewer
OhioLINK is very interested in Motion JPEG2000
as an archival format for moving image objects. We would like to
explore the possibility of transcoding Motion JPEG2000 to Flash Video (FLV) --
possibly in realtime, otherwise in batch -- for access by users through
a Flash player.
(Note: OhioLINK is a licensee of the Kakadu toolkit for JPEG2000.
Although we would prefer an end-to-end open source solution, Kakadu is
available for OhioLINK JPEG2000-related projects.)
On behalf of the Sakai community,
OhioLINK is interested in mentoring these projects (culled from a list
provided by Charles Severance through his blog posting)
that are related to our own work of large-scale content management and
services. When considering these project ideas, please note Chuck's
Here is a list of projects in Sakai that coudl be done by a
talented individual in a fixed period. All of these efforts are on
Sakai's long-term roadmap but none are on the short-term roadmap.
Generally these are not in the "Sakai core" areas - they add
functionality rather than trying to refactor existing mature technology
so they can be done without requiring much coordination with the rest
Each of the tasks would be useful even if partially completed.
the tasks would naturally fit in a Sakai contrib area. Each of the
tasks are relatively simple to describe at a high level but would
require any individual to do a lot of research to figure things out.
That individual should not expect to be "spoon fed" all the decisions
and design - and just sit and code. Part of the challenge is to truly
figure out "what to do" and "how to do it".
The individual should expect reasonable mentoring to get high
questions answered but should expect to be looking at a lot of code in
the beginning of the effort. A key aspect of the sumer of code is that
people taking these tasks cannot be a "drag" on existing resources
executing the short-term roadmap. High level mentoring can come from me
and others and tactical mentoring should come from the Programmer's
If folks want more detail - let
- I am perfectly happy to have an hour-long phone call with anyone who
is ready to spend a sumer or more working on any of these tasks - but
until a resource shows up - these will continue to sit on the
Please contact us before
submitting a project proposal to Google for an item not on this list.
- Build a set of HTTPUnitTests for Sakai Functionality (in
OhioLINK's interest, particularly related to ContentHostingService.java)
- Integrate JackRabbit's WebDav in Sakai
- Add Pluto to Sakai (JSR-168 Support)
- Extend the Sakai JSR-168 portlets to implement delegated security
- A Sakai Portal that does HTTP Proxy (i.e. eliminates iFrames)
- Build support for IMS Tool Interoperability Producer into Sakai
Open Source License
to use the Affero General Public License (in advance of changes
anticipated in GNU GPLv3). Please indicate in your application if you
would prefer to use a different open source license.
Coding Languages, Standards
Depending on the particular application, Perl or Java is the language
of choice for particular applications. (Languages are listed on the project ideas
page when it is strongly encouraged that an implementation use one
language over all others.) In general, proposals that use a language
already supported at OhioLINK will be viewed more favorably than those
that do not.
OhioLINK does not have strict coding standards. We expect proper
internal documentation and comments, including correctly formatted
JavaDocs where appropriate, following typical coding conventions.
We use Eclipse, NetBeans, and good ol' vi as development
environments. Your tastes may vary.
Source Code Repository
OhioLINK runs a Subversion source code repository for our projects.
You may use that for your Summer of Code project, or you may use
another repository. Be sure to read Google's answer
to the question of where coding must be done, though, if you choose to
use another repository.
Google has provided some suggestions on writing your application:
"24. What should an application look like?
Your application should include the following: your project proposal,
why you'd like to execute on this particular project, and the reason
you're the best individual to do so. Your proposal should also include
details of your academic, industry, and/or open source development
experience, and other details as you see fit. An explanation of your
development methodology is a good idea, as well. Note that there is a
word limit to proposals, so be prepared to supplement your proposal
text with links to an external site. However, you should still plan to
provide an abstract of your proposal, including a brief list of
deliverables, via the Summer of Code site to ensure that your work
receives sufficient review; terse applications tend to look like
incomplete applications during the review process." http://code.google.com/soc/studentfaq.html#24
We suggest a proposal format that mirrors that of the Perl
Where can we contact you?
A short description.
Benefits to the OhioLINK and higher education community
Quantifiable results e.g. "Improve X modules in ways Y and Z" or
"Add capability X to function Y"
A more detailed description. You can't be too detailed.
How long do you think the project will take? (No longer than
three months, of course.) What are the milestones?
Who are you? What makes you the best person to work on this
Remember that all proposals must be submitted through the Google Summer
of Code website to be counted as part of Google's program.
If you correspond with us about an idea and we think you intend to
apply to the Summer of Code program, we'll remind you that your
proposal must be submitted through Google's website from May 1st to May
8th, and we cannot take responsibility for your submission if you don't
follow Google's processes. Don't be too concerned if the technical
details are not all worked out; if your proposal is selected we can do
that in the early days of the project. But remember that all Summer of
Code projects should be large enough for you to work on full time for
almost three months.
Peter Murray http://www.pandc.org/peter/work/
Assistant Director, Multimedia Systems tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network Columbus, Ohio