Earlier this year I posted a summary of planned JPEG2000 activity in the Google Summer of Code. As you may recall, there were two project: one mentored by the Mozilla Foundation and another by FFmpeg. This post is a summary of the results of the efforts of the GSoC students.

JPEG2000 in Firefox

I was able to successfully create XPIs for the three major platforms that enable in-line decoding of JP2 images. [This week] I have updated trunk (Firefox 3) builds for Windows and OS X posted to http://eschew.org/test/jp2/xpi/, and will make Linux and Firefox 2 builds in the next few days (hold me to it!). Once I have the major platforms covered, I’m going to submit the extensions to addons.mozilla.org.

We also talked about the chicken-and-egg problem of getting JPEG2000 support into the core browser code. The crux of the problem can be summarized as “why include J2K support in the core browser when it is hardly used?” followed closely by “why use J2K when users would have to install extra software to see the images?”

I think, down the road, a list of major users of JP2 would be helpful, but the folks who work on Mozilla full-time are caught up with the transition from the 1.9 version of the the core code (Gecko), to version 2.0, a fairly major task. Once the dust from that has settled down, I think Stuart Parmenter would be much more receptive to the idea of adding an image decoder to Gecko. Until then, I doubt it would hurt, but I also suspect it would fall on deaf ears.

[ Update 20071101T0859 : Ben posted a message on his blog with the details of building the JP2 renderer for Firefox using the source code. Thanks, Ben! ]

Congratulations to Ben for taking the JPEG2000 integration into Firefox this far. I believe your work will have long-lasting impact.

JPEG2000 in FFmpeg

Kamils jpeg 2000 encoder and decoder, arent in good shape yet (only 2 out of 50 encoded images can be decoded by jasper, only 2 of 23 reference jpeg2k files can be decoded by kamils decoder), but then please dont forget that writing an encoder and decoder at the same time is harder then just one of the 2

Hopefully Kamil will be able to continue his work and bring JPEG2000 to FFmpeg.

OhioLINK is not participating in the Google Summer of Code this year (too many other things going on for our staff to be effective mentors), which is why it is refreshing to see work on the wider adoption of JPEG2000 — one of our core goals — continue on other fronts. Among this year’s 900 projects accepted by mentors are two that involve J2K. All of this is welcome news, coming in the same month that Adobe is questioning the need for JPEG2000 support in Photoshop. My public gratitude goes out to Google for their third year of offering financial and logistical support to their Summer of Code program.

JPEG2000 in Firefox

JPEG2000 in FFMPEG

The text was modified to remove a link to http://www.third-bit.com/soc2007.html on January 19th, 2011.

The text was modified to remove a link to http://code.google.com/soc/ffmpeg/appinfo.html?csaid=1CBF43B104682F6 on January 20th, 2011.

The text was modified to remove a link to http://code.google.com/soc/mozilla/appinfo.html?csaid=C7B9CCBBF96648B3 on January 20th, 2011.

OhioLINK was excited and privileged to participate in the second annual Google Summer of Code — a program to inspire young developers and provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer, and to support existing open source projects and organizations. This is the first of three posts summarizing the efforts of three students; this one details the work of Juan Pablo Garcia Ortiz, a Ph.D. candidate at the University of Almeria in Spain, to build a JPEG2000 JPIP Streaming Server and Client Browser Viewer Applet. This is an edited version of his final report.

The final applications are the ‘jpip_server‘ and the ‘J2KViewer‘ — both of which can be found in the OhioLINK subversion repository. Please note that both are built atop the Kakadu JPEG2000 code library, only a portion of which is included in the OhioLINK subversion repository. ¹

JPIP Streaming Server

The multi-threaded mechanism is implemented with the Linux ‘pthread’ library and uses one thread for each client socket. The source code is written in C++, using the STL library to simplify the code, making it more legible, and orienting it to the object oriented programming philisophy. The different modules of the program are:

• report.cpp (report.h): For the class ‘report’, used to generate the applications logs.
• sock.cpp (sock.h): For the class ‘sock’, used to simplify the sockets work in Linux.
• j2k.cpp (j2k.h): Contains the class ‘j2k_image_file’, used to abstract the work with J2K images. It also contains the necessary code to initialize the Kakadu message handling system.
• jpip.cpp (jpip.h): Contains several classes to support a basic version of the JPIP protocol, over the Kakadu library.
• jpip_server.cpp: The main module.

It is recommended to start from a freshly unpacked (but not yet build) version of the Kakadu library source code (version 5.1). To build this JPIP, follow these steps:

1. At the top level of the Kakadu source directory, checkout the ‘jpip_server’ directory from the OhioLINK Subversion respository. The Subversion URI is https://drc-dev.ohiolink.edu/svn/jpip_server/
2. Change the current directory into ‘jpip_server’ and call the script ‘kakadu_rebuild‘. The script will create the Kakadu directory structure, apply some necessary patches, and build the Kakadu libraries. Please note that this script was written for Kakadu version 5.1 and the patches may not be required in subsequent versions.
3. Run ‘make’ (inside the jpip_server directory)

The accepted parameters by the server can be seen executing ‘jpip_server -u’. The images served by the server must be, by default, in the same directory. The command line option ‘-ipath’ allows you to define a base path for all the requested images. This server can be tested with the ‘kdu_show’ application of the Kakadu package. (kdu_show is a Windows application, but can be executed in Linux with WINE without problems.)

JPIP Browser Applet

1. Checkout of the ‘J2KViewer’ directory from the OhioLINK Subversion respository. The Subversion URI is https://drc-dev.ohiolink.edu/svn/J2KViewer/.
2. From within the J2KViewer directory, run ‘make’.

The build process creates a JAR file containing the viewer applet. It’s correct use would be to sign it with a official signature and include it into the appropriate Web page as an applet. The applet accepts the following parameters:

• “Image“: required, specifies the JPEG2000 image to view. If it’s a local image (not typical), this would be a path name (for example ‘/home/jportiz/image.jp2‘). If it’s a remote image (the typical usage) through the JPIP server, it would be a JPIP URI (for example, ‘jpip://server:9000/image.jp2‘). Do not include any JPIP parameters in this URI.
• “MiniViewWidth“: optional, specifies the width, in pixels, of the mini-view.
• “MiniViewHeight“: optional, specifies the height, in pixels, of the mini-view. The final mini-view size will be the maximum multiple by 2 size of the image that can be included within the specified mini-view size. By default, the mini-view size is 250×250.

To be able to test easily the applet, you can run ‘make test‘ to create a ‘test.html’ file and a ‘test’ script. This script launches the applet viewer with the ‘test.html’ page. It is necessary to modify the ‘Image’ parameter of this HTML page to set the appropriate image location.

To test the applet within a web browser, you can run ‘make test-signed‘ to create a signed JAR file, then open ‘test-signed.html’ with a Java compatible browser. Before opening the HTML page, it is necessary to modify the ‘Image’ parameter within the page to set the appropriate image location.

The viewer has a simple UI. It has a toolbar with two buttons, one to select the interaction mode (zoom or pan) and another one to show the mini-view window. There is a status bar where is showed the real image
size and the current scale, and in the right side, the current number of bytes read. In the center panel is the image — initially scaled by 2 fo fit it in the applet size. This behaviour can be modified easily in the code.

The mini-view window can be moved to any part of the main window. If it’s closed, it can be showed again with the associated button of the toolbar. The mini-view contains a red rectangle outlining the actual view of the main window. This red rectangle can be moved by dragging it and the corresponding view in the main window will be updated.

The applet requires that the Kakadu JNI library is stored in the user home directory (‘C:\Document And Settings\User’ in Windows and ‘/home/user’ in Linux). The applet detects if this library exists and if it is not found the applet allows it to be download automatically from the OhioLINK repository and stored it in the user home directory.

This is a brief description of the implemented classes:

• ChunkedInputStream: An InputStream derived class to decode HTTP chunked messages.
• HTTPMessage: The base class of all the HTTP message classes.
• HTTPRequest: Identifies a HTTP request.
• HTTPResponse: Identifies a HTTP response.
• HTTPSocket: Derives from Socket and allows HTTP messages to be sent and received in an easy way. In only supports send HTTP requests and receive HTTP responses (a client socket).
• ImagePanel: A GUI panel that can be included in any image browser. This panel has the necessary methods to load images and control its visualization. It supports the display of a mini-view of the image. All of the image navigation is controlled directly within this panel.
• ImageWindow: An interface to implement all the parent windows that include an ImagePanel obejct.
• J2KCache: A wrapper class for the Kdu_cache Kakadu class. This encapsulation allows another J2K engine to be used while avoiding the need to modify the design and code of the applet.
• J2KEngine: Contains all the necessary code to initialize the J2K engine. In our case, the Kakadu J2K engine.
• J2KException: A Exception derived class to identify the exceptions generated by the J2K code.
• J2KImage: This class contains all the necessary code to work with J2K images, local files as well as remote URIs. If the image is local, the Kakadu library functions are used to open it. If the image is remote, a J2KReader object is used to retreive the content.
• J2KImageView: Defines an image view, renderable on the screen. This image view is defined by its coordenates, size and resolution level.
• J2KReader: An implementation of a basic JPIP client to read the necessary data of a specific image view.
• J2KRender: Implements the rendering thread of the image browser. This thread is always generating the current image view. It stops when this view is rendered and the image content is completed (if the image is remote, this means that all of the required image codestream blocks have been received).
• J2KViewer: The main class of the application.
• JpipConstants: Defines several global constants related to the JPIP protocol.
• JpipDataInputStream: An InputStream-derived class to extract JPIP data segments from an input.
• JpipDataSegment: Contains the information of a JPIP data segment, which can be either an EOR message or a data-bin segment.
• Mutex: A simple mutex implementation in Java, used to avoid threads conflicts when accessing to the image data.
• StringInputStream: An InputStream-derived class to extract strings from inputs without buffering. Useful to decode HTTP headers and chunks lengths.

The viewer follows the JPIP philosophy in the code structure, especially with remote images. That is, when it is displaying a remote image, there are three threads running in parallel: one for the main GUI, a second for the JPIP comunication that is making the requests and filling the cache with the received data, and a third to render the cache content on the user’s display.

The Java JPIP viewer has been tested in Windows and in Linux. In Windows it has been used the Sun JVM/JRE 1.5 without problems. However, in Linux, this JVM/JRE version seems quite unstable, requiring the previous version, 1.4.2. In Linux the Blackdown JVM 1.4.2 as well as the Sun JVM 1.4.2 have been tested with succesful results.

Future Development Goals

Another feature that was part of the original design but was not completed due to time pressures was to integrate the JPIP server and client into the FEDORA digital object repository system. There is also room for a lot of more features: support of the HTTP-TCPtransport protocol, allow for the display of the image metadata, more GUI utilities like the ability to save the image as a local file for image processing, increase the set of supported JPIP parameters, etc.

Gratitude and Acknowledgements

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/jpip_server/ on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/J2KViewer/ on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/jpip_server/kakadu_rebuild on January 13th, 2011.

Footnotes

1. Editorial comment: although not released with an open source license, the Kakadu JPEG2000 code library is available at a very reasonable cost. Juan Pablo’s efforts initially started with one of the open source JPEG2000 libraries, but it was quickly determined that the Kakadu library was required to meet the demands of the project proposal.

OhioLINK is pleased to mentor three students working on projects for Ohio’s higher education and libraries around the world during the Google Summer of Code 2006. The three projects are:

JPIP Browser Applet and Streaming Server

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.

The server side of the JPIP client/server pair will connect to OhioLINK’s existing FEDORA digital object repository. 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.

Running in the user’s browser, the JPIP applet will request portions of a JPEG2000 image in FEDORA at a specified quality/resolution/clip and the FEDORA/JPIP disseminator will retrieve and return to the applet the requested precincts/packets directly from an archival master in the repository.

Communications System

The project consists of a set of two clients, written in Java, on the basis of the Internet Relay Chat (IRC) protocol. One client is targeted at patrons (readers, researchers, scholars, etc.); the other aims at facilitating the needs of librarians and other staff. The server end of the chat system consists of an IRC daemon. The clients, being pure Java, can easily be refitted into a number of embeddable modules, including browser applets, JNLP packages, NetBeans or Eclipse platform modules, etc. Using the ubiquitous and well-developed IRC as the underlying layer provides additional possibilities for sophisticated users and administrators, namely using IRC clients of their choice, using IRC bots when staff are unavailable, etc.

The project consists of two parts: the first being the implementation of a generic IRC client in Java with a GUI, and the second being the addition of advanced functionalities specifically for the purposes of OhioLINK and member libraries: identity branding; ability to store and send “canned” messages; ability to transfer patrons among librarians; ability to email transcripts of sessions; ability to automatically email transcripts at the close of a session; a survey for user feedback; and the ability to service / monitor multiple queues.

Video Snapshot Tool

This project will provide users with a capability to browse video collections to see ‘snapshots’ of what each video contains, with index pointers to characteristic frames (scene pointers), equally distant pointers, and user-defined pointers (which are saved within users profile, something like video-browsing history). There will be a timeline with predefined pointers (scene and equally distant pointers) which cannot be changed, and sliding pointers that are user defined (user adds them, deletes them etc.) which can have user comments. Every pointer will have a snapshot that will be shown to the user when he positions cursor over that pointer. The user will also be able to play the video from a selected pointer.

With nearly 100 mentoring organizations to choose from, there were 3050 students submitting 6338 proposals to this year’s Summer of Code. OhioLINK received 21 applications.

Although we were a little concerned right about this time last week, you came through with a wonderful suite of applications with OhioLINK as the mentoring organization for the Google Summer of Code. In the end, we are blown away not only by the increase in quantity over last year, but also the quality as well. We received seven for the video snapshot idea, five for the grid-based bulk video conversion tool, one each for the JPIP-based disseminator and applet client, plus a half-dozen proposals for things we didn’t have on our list.

We’ve got four mentors right now looking through the applications and I am recruiting a few members from the Ohio Supercomputer Center to help with the array of grid-based proposals. So to everyone that applied — thank you! — and relax for a little bit while we work through your applications.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/ProjectIdeas.

OhioLINK has received fewer applications for the Google Summer of Code than last year and have a number of areas not yet covered by proposals. Our project ideas page has suggestions related to applications we currently have under development, most dealing with applying JPEG 2000 to still image and moving image files. We have also listed library-related projects for the Sakai collaboration and learning environment.

Google is sponsors the Summer of Code to “keep student’s programming skills sharp” over the summer by pairing students with mentoring organizations to create open source applications. OhioLINK is participating as a mentoring organization and welcomes applications for projects in the area of library services and information management.

In general, we work in the area of information retrieval, search result visualization, knowledge management, and automated description. What is it that you wish your academic library did better? Is it a 12 week project? We’re interested in hearing from you.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/ProjectIdeas.

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.

OhioLINK-generated Ideas

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 for Fedora

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 mirror
• 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.

Bulk 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.

Prototype 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.)

Sakai-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 preface:

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 of Sakai.

Each of the tasks would be useful even if partially completed. Each of 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 level 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 Cafe group.

If folks want more detail – let me know – 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 back-burner.

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

OhioLINK prefers 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 and Tools

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.

Proposal Format

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 and PostgreSQL foundations:

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.

The text was modified to remove a link to http://code.google.com/soc/studentfaq.html.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/ProjectIdeas.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/ProjectIdeas.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/OpenSourceLicense.

The text was modified to remove a link to http://code.google.com/soc/studentfaq.html#44.

The text was modified to remove a link to http://code.google.com/soc/studentfaq.html#24.

The text was modified to remove a link to http://source.sakaiproject.org/fisheye/viewrep/Sakai/content/trunk/content-api/api/src/java/org/sakaiproject/content/api/ContentHostingService.java on December 31st, 2010.

Google is sponsoring the Summer of Code, a program designed to introduce students to the world of Open Source Software Development. OhioLINK is pleased to participate again as a mentoring organization, furthering the development of information technology in academic libraries in Ohio and around the world. We have a page on our development site describing OhioLINK’s participation and projects; take a look, augment or add your own (feel free to read the project documentation through the ‘Wiki’ link above and suggest other ideas), and apply to participate. Questions about the program? Take a look at Google’s participant FAQ. Questions about the suggested projects or about OhioLINK? Contact Peter Murray.

The Ohio Library and Information Network, OhioLINK, is a consortium of Ohio’s college and university libraries and the State Library of Ohio. OhioLINK’s membership includes 17 public universities, 23 community/technical colleges, 44 private colleges and the State Library of Ohio. Funded by the Ohio Board of Regents, it serves more than 600,000 students, faculty, and staff at these 85 institutions with a consolidated catalog of library items across the state, a physical transport service that delivers those items to users within 48 hours, and cooperative buying of journals and research databases.

The text was modified to remove a link to http://code.google.com/soc/ohiolink/about.html.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/wiki/GoogleSummerOfCode2006.

The text was modified to remove a link to http://code.google.com/soc_application.html.

The text was modified to remove a link to http://code.google.com/soc/studentfaq.html.