The AbiSource project provides a free, fast, powerful word processing application, AbiWord. A live, real-time collaboration feature, AbiCollab, has been added to the development version, allowing an arbitrary number of users to work together on the same document at the same time. While keeping all copies of the document in sync is of moderate difficulty when entirely separate parts of a document are edited, edits that are close to each other provide remarkable challenges in synchronization and usability: how do we maintain the integrity of the document for all viewers, yet not surprise any of them with unexpected, if technically "correct," behavior? I will systematically explore these corner cases, finding where synchronization is lost and where synchronization results in counter-intuitive behavior. I will then work to resolve the problems that I find, so that AbiCollab is released with the next major release of AbiWord as a robust, stable addition, in addition to being highly innovative.
In addition to my work on the AbiCollab algorithm, I will also use my knowledge of the Windows platform and my experience building and testing on Win32 to produce a solid Win32 GUI for the AbiCollab feature, which is currently Linux-only (GTK+).

The cross-platform word processor AbiWord has great interoperability. The project's website states: "AbiWord is able to read and write all industry standard document types, such as OpenOffice.org documents, Microsoft Word documents, WordPerfect documents, Rich Text Format documents, HTML web pages and many more."

However, there is a new format that will eventually become an "industry standard" which AbiWord does not support yet: Microsoft's OpenXML initiative. This project aims to create a filter plugin that will import a ".docx" OpenXML document by translating it into AbiWord's native data model.

The project will have two components: an extensible "backend" which does the work of converting ".docx" files, and the actual filter plugin, which will use the backend to integrate the functionality into AbiWord itself.

Since the backend's design will be as modular as possible, one of the goals is to allow the eventual extension of its capabilities so that it will be able to convert both ways. Once that is done, an export filter can hopefully be written easily to complete Abiword's compatibility with OpenXML.

Provide a complete solution to work with annotations in AbiWord.
- Create, edit and remove annotations.
- Create annotations from existing text or from “scratch”.
- Allow AbiWord-generated annotations.
- Allow users to show, hide and print them.

Abiword currently offers a grammar checking tool to the user through a plugin that uses link-grammar as back-end. The only available language for checking is English, as supported by link-grammar. Moreover, the checking is slow and the results are not clear to the user, with no further information on the errors detected.

I would like to enhance this tool by allowing to connect other open source checkers to Abiword. The change will make it possible for users to count on more developed tools, which have features such as explaining the errors found and suggesting a correction. Also, it will allow grammar checking on a higher range of languages, as supported by the different checkers.

Project Overview
This project will add a new feature to the way groups are presented. Groups will be able to be unlocked from their vertical arrangement and float freely and locked to either a vertical or horizontal arrangement. In order to keep some sense of order, groups will be able to snap to both other groups and the edges of the screen. This will give users more freedom in the way they arrange all their currently open windows by taking advantage of all the free space on the screen.

Adium's AppleScript support is somewhat incomplete and buggy. I will implement a dictionary file that addresses many of the these problems and will provide Adium scripters will plenty of opportunities to expand the application. Hopefully, this will get more Applescripters excited about using Adium.

Since my project last year was scrapped after the fact due to the deprecation and simultaneous breaking of the Java Bridge by Apple, I'd like to re-implement most of the features it had into Adium again, since Adium's XMPP support is still very bare-bone.

Due to vivid discussions with the Adium and libpurple developers, I've concluded that going with libpurple-based XMPP is the way to go.
I reviewed the Pidgin 2.0 application and found it to have many features that are absent in Adium. These will have to be integrated into the user interface. Further, some missing features are known to be incompatible with Pidgin's philosophy. Sean agreed that we're allowed to add features to XMPP/libpurple, even when they don't benefit Pidgin itself.

Features that are implemented in Pidgin I'd like to add to Adium are:
* Full MUC support (roles, nick registration, nick change, channel setup, channel subject) -- this will probably require co-operation with whoever will work on the improved groupchat support
* Forms support (required for many features) -- this is going to be complicated due to the nib-centrism of Cocoa
* Console for directly sending stanzas and logging all XMPP communication

Features that I'd like to implement in libpurple and add to Adium are:
* Gateway support (registration, log on/off)
* PEP (http://www.xmpp.org/extensions/xep-0163.html) -- This will be a bit complicated to implement, since there is no support for this in any server yet. However, there's an experimental patch to ejabberd for it, so maybe I can use that one for testing.
* Based on PEP, implement some protocols that require this, like user tune (http://www.xmpp.org/extensions/xep-0118.html), user avatar (http://www.xmpp.org/extensions/xep-0084.html) and user nickname (http://www.xmpp.org/extensions/xep-0172.html)
* fix OTR-support (http://trac.adiumx.com/ticket/5558)
* http://trac.adiumx.com/ticket/4695
* Discovery Browsing. This will probably need some previously unthought of user interface (the main reason why Pidgin refuses to implement it is the weird interface usually used for it). This would enable MUC channel listings, ad-hoc commands (http://www.xmpp.org/extensions/xep-0050.html), looking up gateways and other nice features.
* Maybe Invisible Command, depending on whether this can be implemented using libpurple (it requires being silent to certain requests).

The Adium instant messaging client supports many popular messaging protocols including AIM, Yahoo, Google Talk, and MSN. Adium currently also supports other protocols including Bonjour, a protocol most widely used by Apple's iChat. Unfortunately, Adium's current support for Bonjour messaging has numerous bugs and lacks important features. This project aims to modernize Adium's support for Bonjour.
 Adium currently uses the libezv library to support messaging with iChat, however, important bugs such as the inability to send multiline messages and improper reporting of the current users online significantly detract from the usefulness of this library. Thus, this project will fix these outstanding bugs. Another function of this project will be to switch libezv to use Apple's well-maintained mDNSResponder. Supporting file transfer between Adium and iChat over Bonjour is the third major goal of the project. However, time permitting, the project will lay a groundwork for audio/visual chat using Bonjour.

Audacious Media Player has evolved very much in the last few months, thus becoming a good and mature music player. It is the best alternative for XMMS - the most common player in the past 10 years, in Linux. The plugin-based infrastructure allows a great variety of media files to be played. Most of the plugins are fully functionable, while some of them lack certain features, or they are marked as "ugly" because of their code lookalike, their instability or usability. The main goal of this task is to implement suport for CD-Text (see: http://web.ncf.ca/aa571/cdtext.htm for more info) in the existing CDAudio plugin. To achieve this goal, the guidelines found at the previously given link will be used, as well as some code from the K3b project (http://www.k3b.org/).

Synopsis
--------

This project aims to get rid of some leftovers from XMMS and BMP code. I would rewrite the widgetcore as real GTK2 widgets.

Project: Audacious Media Player - additional NewVFS transports

Audacious uses a implementation of a virtual file system (called NewVFS) in order to abstract the file access. NewVFS transports currently enable audacious to play URL's for streaming content (such as http and https).

In my SoC project I would like to add support for some streaming protocols that audacious is currently missing, including the following URL types:
   * lastfm
   * mtp
   * daap
   * ssh
   * smb
If the time allows, I would add support for even more as required by the community.

Time Schedule:
   * In the first 1-2 weeks I'll get familiar with the source code and the devs crew. I'll try to understand how any other free software applications implement these features, and if possible 'steal' some ideas or code samples from them. I hope my my mentor will help me finish this stage as fast as possible
   * The next weeks I'll dig into the source and write code to implement the features.
   * The following 2 weeks I will do mainly bug-fixing.

Shall I'll finish faster than the SoC deadline occurs (hopefully), I'll make myself useful by adding other features audacious is lacking, or improve the existing ones. Anyway I intend to remain an active developer afterwards since audacious is my main music player, and I'll like to make it become better.

With the advent of multi-core computers even for basic desktops, parallelizing an application which needs huge amounts of CPU power can bring big performance benefits. Using threads in applications to listen for incoming data (e.g. via sockets) has the benefits of not blocking the rest of application or not having to poll in a loop; but with N CPUs/cores an application with huge CPU usage can run up to N times faster (using a fraction 1/N of the time compared with single-threaded implementation) in the critical parts -- provided that is highly parallelizable, of course.

One of the big problems of using threads is the different implementation of them in the different platforms. However, this can be circumvented with the use of Boost.Threads (or maybe alternatives such as OpenThreads).

This project aims to implement core parts (especially the rendering stages) in a multithreaded way, so the application can benefit from powerful hardware in a platform-independent and reliable way.

I propose to implement the deep shadow mapping algorithm as described by Lokovic and Veach [http://graphics.stanford.edu/papers/deepshadows/deepshad.pdf] as a new feature for the Aqsis renderer. This algorithm, like traditional shadow maps, stores a rectangular grid of pixels, but unlike standard shadow maps, the data stored at each pixel is a visibility function, rather than a depth value, representing the fraction of initial light energy that reaches a point at arbitrary depth. This is like having an alpha channel available as your shadow map at every z-depth, giving you semi-traasparent shadows and colored shadows without raytracing. Since these alpha maps themselves are not stored, only the functions used to compute them, storage for this algorithm is very low, but sampling can still be parallelized.
I will correspond with students implementing multi-threaded functionality of the core REYES renderer so that shadow mapping is ready for threaded execution upon release.

Last year's SoC saw Ardour gain the ability to record MIDI data in addition to audio. While the underlying functionality is there, in order to be competitive with professional sequencers a nice GUI interface for editing MIDI data is needed (and highly requested by Ardour users and the Linux audio community in general).

This project includes the implementation of a piano-roll style MIDI note editing interface in Ardour, and the ability to send control messages (MIDI CC and NRPN) with an interface similar to the existing one for automation.

n.m panning

Name: Christian Muise
Email: christian (dot) muise (at) gmail (dot) com
Site: http://www.haz.ca/

## Proposal ##
 Panning a mono sound source to an arbitrary speaker setup, such as 5.1, is required by any studio level audio recording software. A properly written panner for Ardour to any of the standard home theatre setups would be a huge asset to the software.

 Having this capability would allow users of Ardour to mix sound for Dvd videos or even DVD-Audio mixdowns. Providing this feature to the Ardour user base is something that would take Ardour to a new level.


## Why Me? ##
 The task of gearing an audio application to spacial panning is one that requires a great deal of mathematics and programming knowledge. This is primarily why I'd be perfect for this project. I have a strong mathematical background through the courses taken in University, and programming for audio is a huge interest of mine that I've not been able to tap into as of yet.

 I am currently a student in a Sonic Design program at Carleton University. Because I have a strong background in music and audio recording combined with my primary major in Computer Science, I would fit quite nicely with the Ardour team. I have used Ardour with Agnula quite a bit in the past, and I am currently shifting my home studio setup to use that OS with Ardour exclusively.


## Why You? ##
 Having a hand in creating the software I will be using would be the best area for me to work in. I want to solidify a place in the open source community where I could be the most helpful and interested, and Ardour would be one of the best projects providing this.


## Purchases ##
 For this project, the initial funding would be used to up my current setup from 2.0 to 5.1. This would simply involve purchasing new speakers for the Delta 1010 Soundcard currently being used. I feel that it is reasonable for the student to input some of the funding for the gear needed to complete the project.


## Milestones ##
May 28th: Project plan figured out, and code base reviewed.
May 31st: 5.1 speaker setup purchased/placed
June 21st: Mathematical research complete for panning
July 9th: First draft of code for 5.1 complete
July 17th: Mathematical code optimized for real-time
Aug 2nd: Second draft of code complete for arbitrary speaker setups
Aug 20th: Final implementation ready to be released


## Bio ##
 I am currently finishing my 5th and final year of a Computer Science degree with a Minor in Math at Carleton University, Ottawa. I hold a leadership role in the Robotics Club, Game Dev Audio Group, ACM Contest Teams, and the student society for Computer Science. I have interests ranging from AI to audio to robotics, and spend most of my spare time trying to find slick ways of combining all of them into a single project.

 I was a successful applicant of Google's Summer of Code in both 2005 and 2006. While I have adopted a fair amount of Open Source solutions over the last few years, I have not yet had the opportunity to become part of a development community for which I would be well suited. This is my goal for Summer of Code, 2007. More info can be found on my website.

Eclipse UML2 for ArgoUML

Project Goals
The goal of my project is to advance ArgoUML model subsystem to UML2.1.1 with the Eclipse UML2 project.

Details
The hole UML2 is too big for 3 months of summer, so I propose a subset of UML2. The main interfaces from argouml-core-model (ModelImplementation, ModelManagement and others that are required). Then I would choose an incremental approach on language units: Classes, Use Cases.
Eclipse UML2 is suited for both Eclipse plugins such as ArgoEclipse and for standalone applications such as ArgoUML. I tested it by building a small standalone application in Java that uses Eclipse UML2. You can find details here: http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20781

UML is a de facto standard in commercial software modeling. The language provides a rich set of constructors which enable the specification of systems ranging from simple information systems to sophisticated multi-threaded ones. Despite of the fact of being mainly target to specifying software systems the language also provides means to be adapted to other domains, as multi-agent systems, tests, and many others. This project aims to extend ArgoUML in order to support UML profiles, the proposed features include (but are not limited to): definition, application and management of profiles.

The sequence diagrams subsystem in ArgoUML are in need of some work. It was coded a long time ago, and now it isn't consistent with the rest of the ArgoUML code. I want to refactor this decreasing the maintenance cost of the subsystem in the future.

During the development programmers need to have a report of the architecture of the future application. This report can also be useful for future development and not only for programmers.
 
At this moment ArgoUML do not have the possibility to generate full-scale report of the designed architecture. ArgoPDF as a part of ArgoUML will make it easy to generate report as pdf file.
While making a report, you will be able to compose title page by specifying different parameters.
You will be able to choose the diagrams to include in the report.
Setting up parameters will be easy through an intuitive graphical user interface.

ArgoPDF will be implemented in Java using a free powerful java library for generation pdf files - iText (http://www.lowagie.com/iText/).

ArgoPDF will be a part of already existed ArgoPrint subproject.

The GEF project is developed to provide a graph editing library for other graph applications, e.g. ArgoUML. It contains several diagram elements and enables the users to interact with them for moving, resizing, reshaping, dragging and dropping, etc.

The GEF project is based on swing and java2d libraries. This GSoC project aims to abstract away the Swing/Java2D functionalities in the GEF project into a separated package and provide an alternative GUI alyer.

Apache Axis2 uses Axiom as its underlying object model which provides an efficient yet less memory-intensive object model. The current implementations of Canonical XML and Exclusive XML Canonicalization specifications of The Apache XML Project use DOM underneath. These implementations are used in Axis2 in providing WS-Security with great hassle due to the expensive conversion between DOM and Axiom.

The intention of this project is to eliminate such conversion and to improve the efficiency for relying parties of XML canonicalization by implementing both specifications based on Axiom. Eventually it would provide a vital improvement to Axis2 as its WS-Security implementation heavily depends on XML canonicalization.

This is an attempt to implement Mail Transport (SMTP/POP3) support for Apache Axis2/C. Currently Axis2/C has the HTTP transport as the general transport.

At the end of the project Axis2/C will have the mail transport support in addition to the HTTP transport. The project is going to be done keeping extensibility in mind so that the other protocols(ex.IMAP4) can be plugged.

As for any other web application framework, one of Cocoon's core functionality is expression handling. Simple yet powerful expression languages (ELs) enable developers creating Cocoon applications query for data they need in clean manner. Even though several ELs are already present in Cocoon their use is now incoherent and they operate on inconsistent Object Model (OM, discussed below). This is a serious obstacle for novice users and makes Cocoon applications more difficult to maintain. In order to address these issues I propose to:
  * revise EL handling implemented in Cocoon's template block and find out if improvements are needed
  * get rid of Avalon dependencies in EL and OM handling code
  * provide consistent, complete object model for expressions everywhere they are used
  * implement converter concept and provide basic converters' implementations
  * refactor at least portion of Cocoon samples so they use new ELs implementation
  * document new architecture, create migration guides and promote the use of new implementation across the community

OpenJPA is a 100% open-source implementation of the Java Persistence API (JPA), which is the persistence component for EJB in the Java EE 5 specification (part of JSR-220).

JPA combines the best ideas of other persintence technology, such as Hibernate, JDO and TopLink
 
The fields BLOB and CLOB of sql are translated for the Java programmer in the java.io.InputStream (for BLOBs) and java.io.Reader (for CLOBs) types, the objective of this project is to provide a serialization in database of these objects in a natural way.

My proposition is to create a software system that will allow,
during the build process of a project, to automatically generate
diagrams of chosen aspects of the project. I would like to provide two
components: a graphical editor and a Maven plug-in.

"The Graphical Editor will offer live (WYSIWYG) preparation of a
graphical presentation of the project by setting such properties as:
     - Type and subset of data, we want to present,
     - What part of the data is to be presented,
     - The method of presenting of each type of diagram nodes (that is,
what attributes of the item will be displayed), and the general "style"
of the presentation. I would like to provide UML-like design.
    - The general layout algorithm
    - The positions of selected locked nodes – which we want to put in a
fixed area. All other nodes will be positioned automatically.
The schema of the diagram created by the editor will be saved to an XML
file.
Additionally the editor may be used as a graphical browser (explorer) of
chosen aspects of the project. The editor will use the Prefuse library
(http://prefuse.org).

The Maven Plug-in (maven-graph-plugin) – will be using the XML file
prepared by the Graphical Editor and the current state of project to
prepare images in various graphic formats (JPG, TIFF, PNG and others
supported by the Sun JIMI library). The plug-in will be able to prepare
the HTML <map> tag for the picture too (to create an active area on web
page containing the image). The resulting file will be ready to use in
the next Maven phases by Doxia or other documenting tool.

The maven-graph-plugin will cope with changes in the project made after
generating the schema XML file. This means that if an object from the
XML file is no longer exists in the project, it won't be visible in the
picture. It also means that if the object is new, it will be placed in
the picture (in a place calculated by the general layout strategy set in
the XML file).
Additionally the user will be warned about any discrepancies between the
expected and actual data and problems with finding space for a new
object. The diagram generation will not modify the XML file, but will
only try to interpret it for the current situation.

During Google Summer of Code time I wish I prepare two connectors
(possibilities to visualize an aspect of project):
    - Dependencies diagram connector – to visualize the chosen project's
subset of the dependencies (internal or external, up to a configured
depth or/and included in a given scope). It will be also possible to
exclude some dependencies from the diagram.
    - Class diagram – to visualize the inheritance and composition
aspects of the class hierarchy. The information will be obtained by
reflection.

Of course the mechanism of the connectors will be universal enough to
make the addition of a new aspect of a project as simple as possible.

* Project Description
    Bayesian filtering is a powerful machine learning tool frequently used in spam detection. However, unintentional or intentional noise could circumvent Bayesian filter (http://bnr.nuclearelephant.com). In unintentional case, it is normal that some common words appear in both spam and legitimate email, which makes spam emails look somewhat similar to legitimate emails. Furthermore, spam mail writer could intentionally inject some words which only appear in legitimate emails. In that, Bayesian filter will be deceived and misclassify a spam as a legitimate email.
    Dobly Bayesian Noise Reduction (BNR) is a preprocessing step to eliminate these noises from email before presenting them to Bayesian filter. The basic idea of BNR is to remove words which are not informative in Bayesian filter and words not consistent with its context. Result shows that BNR will increase the accuracy of Bayesian filter by a wide margin.
    BNR is a feature of DSPAM system (http://dspam.nuclearelephant.com) and there is a reference implementation of BNR alone (http://bnr.nuclearelephant.com).
    The goal of the project is to add BNR into SpamAssassin in a proper way.


* Benefit to SpamAssassin Community
    Increase the accuracy of Bayesian filter with affordable performance penalty and minimal administrative overhead


* Deliverables
    Perl module for BNR, integration with existing Bayesian filter and learner, sql script for new data structure, documents for new configuration entries, performance document, etc

Batik's browser application has only the basic support for inspecting a document, through the DOM Viewer component.

In my application I propose the possible ways of enhancing Batik's document inspector.
This can be achieved by not only browsing the DOM tree, but also allowing the editing of the document through the DOM Viewer. Therefore, following options should be implemented:
1. The user – requested option which would update the state of the DOM Viewer from the content of the document,
2. The options for adding new elements and attributes, and editing the listed ones.

The key is to use intuitive GUI interface and write a set of methods to support the manipulation of the document throught the GUI.

The user should be able to add new nodes to the Viewer's tree, add new attributes in the attribute list or edit the value of the existing ones and see the changes on the canvas. After performing any of the changes, the document referred by a Viewer has to be refreshed.

The final goal here is to enhance document manipulation through the DOM Viewer component, so the user can easily browse and edit the content of the document.

Just as the bug reporter said: In the spamassassin system(http://spamassassin.apache.org/), every spamd instance (fork) requires a new connection to be created to the SQL server, then a query happens, and then the session is disconnected. This is quite unnecessary and inefficient. Spamd should actually connect on startup, disconnect on shutdown, and just do queries through that open connection. So we need a persistent database connection plugin.
Fortunately, Michael Parker have fixed the bug by adding a plugin
(http://wiki.apache.org/spamassassin/DBIPlugin) that handles persistent database connection.
However, due to the licensing problem(DBI,Apache::DBI is under GPL,http://www.gnu.org/copyleft/gpl.html), this plugin cannot be made into the main SpamAssassin codebase. we need an implementation under ASL(http://www.apache.org/licenses/).

Main purpose:
1.keep a persistent database connection
2.implement the plugin under ASL

Chainsaw is included in Apache/Log4j. It is a GUI based log viewer which is developed to load log events mainly through the 'Receiver' concept. Via these receivers, Chainsaw can load events generated by various frameworks like log4j, log4net, log4perl, log4cxx and java.util.logging. Other than that, Chainsaw can load log events using XML-formatted log files. Using both these mechanisms, Chainsaw can cater various applications. It's GUI features support a lot when it comes to debugging huge applications.

Currently Chainsaw is lacking some important features which can improve the usability of the tool in a great deal. Tailing capability in the VFS log viewer is one of the major improvements that should be done. There are some other features to implement in areas like receiver creation panel, remembering filter and search expressions between Chainsaw restarts and memory usage as well. And also there will be more ideas arising as this project go on.

This project would be an attempt to implement the required features in Chainsaw after some research to understand the best ways of improving the efficiency. This will improve the usability of the tool in a great deal.

The objective of this project is to improve the integration of the available components in MyFaces, being incorporated the capacity to define skins or styles for define a look n feel of the components in a web page, making a wiki tutorial about using tiles for layout MyFaces components, and solving some previously raised topics in jira of MyFaces that contribute to improve integration between different components available in MyFaces.

The JSF APIs are quite powerful from a component developer's perspective, but as in the majority of cases the flexibility you need for full-fledged enterprise web applications implicates complexity in the daily usage. Ruby on Rails demonstrates that it is more advisable to favor convention over configuration, as this is exactly the principle why Ruby on Rails gained its popularity. Therefore JSF component developers should not have to mess around with writing boilerplate code, but rather modify and complement it where appropriate.

Currently, if you want to implement a custom JSF UI component, the following three steps are required:
- Create a Java class which inherits UIComponentBase either directly or indirectly. This UIComponent class contains the actual Java code representing the logic of the component. It accomplishes rendering either on its own or by using a seperate renderer.
- Register the UI Component by adding the appropriate configuration entries in faces-config.xml. These entries are used both to initialize the JSF application and to provide the possibility for tool vendors to display custom components on a component palette.
- Integrate your component with the desired view technology (i.e. JSP). This involves writing tag libraries and tag library descriptor files.

The problem arises from the fact that you have to keep these three steps align with each other, but that's an annoying and time-consuming task (for example, it can be quite cumbersome to propagate changes appropriately). In the face of these difficulties it seems to be rather conventient to generate components and taglibs using an existing faces-config.xml. This principle is nothing new as similiar projects (for example, maven-faces-plugin and myfaces-build-tools) are already available, but none of these projects are feature-rich enough.

The MyFaces Component Generator improves the ease of component development by using an approved method – convention over configuration. It generates components with default, meaningful behaviour, but of course only if you desire to, as you're still able to use custom templates to alter the generated outcome.

There is lack of a good SVG explorer on the Windows platform. Batik's browser application, Squiggle, allows a user to view and apply only limited transformations to a single document at a time. Also, error handling and document inspection is quite basic. This project will use the existing code base to implement a full-fledged explorer-like application which allows, in addition to existing features, directory navigation, multiple views (thumbnail, film-strip etc.), undo/redo, simple directory search and generally a better user interface than what we have today. The proposed browser will also have support for making changes to the DOM tree and viewing animated SVG files.

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly.
 A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, web page, menu etc, while in object-oriented programming, the smallest unit is always a Class; which may be a base/super class, abstract class or derived/child class.
    Units are distinguished from modules in that modules are typically made up of units.

    The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits.
    Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (i.e. regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified and fixed.

    Readily-available unit tests make it easy for the programmer to check whether a piece of code is still working properly. Good unit test design produces test cases that cover all paths through the unit with attention paid to loop conditions.
    Unit testing helps to eliminate uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.
Unit Testing provides a sort of "living document". Clients and other developers looking to learn how to use the module can look at the unit tests to determine how to use the module to fit their needs and gain a basic understanding of the API.


Limitations:
-----------

        Unit testing will not catch every error in the program. By definition, it only tests the functionality of the units themselves. Therefore, it will not catch integration errors, performance problems or any other system-wide issues. In addition, it may not be easy to anticipate all special cases of input the program unit under study may receive in reality. Unit testing is only effective if it is used in conjunction with other software testing activities.

        JUnit is a unit testing framework for the Java programming language.

        In this project I am going to Convert Derby tests to JUnit and fix bugs in Derby.

An application programmer who is not familiar with JCR API but plans to use Jackrabit should have an example of JCR API and Jackrabit usage. Therefore it is necessary to build up a proper application to put on a demonstration of JCR API features.

Demo application requirements:

- should illustrate JCR API features in full measure
- should illustrate JCR API features complete
- should deal with some non-trivial JCR API use cases along with general ones
- shouldn’t use any extra frameworks (ex. Struts, Hibernate, etc.) in order to pay attention to JCR API features and not to eliminate people who are not familiar with frameworks in question at initial point; therefore the application must be built up with JSP + Servlets + Design patterns
- as a basis for repository realization it is possible to chose both DB and XML-catalog
- shouldn’t to be too large, that is to say that the application shouldn’t be overloaded with architectural components
- any beginner should gain an understanding of demo application knowledge domain
- it is necessary to assure that the application should deploy both on Tomcat and on some AS (Apache Geronimo is preferable)

As a case in point the online-test system μAssessment (muAssessment) is suggested.

Please visit http://www.konnikov.net/GSoC/2007/ for further information.

Motion estimation and mode decision incur a large proportion of the
costs in compressing video. I propose a project to utilise more
efficient algorithms for these features in the Dirac reference encoder.
The focus will be on selection of an algorithm/algorithms which provide
excellent performance whilst being conducive to lower-level optimization
in the Schroedinger implementation of Dirac by use of the liboil library.

This project will give an interface to kamaelia components which can be operated on in a similar way to file I/O, to enable easy kamaelia integration into non-kamaelia-component oriented systems.

[Taken from 'Synopsis' of the Detailed Description]
This project has three parts. Part I is to implement support for the TOC protocol in Kamaelia and to extend the existing IRC capabilities.
Part II is to bridge the AIM and IRC protocols, and create a client that deals with both of them uniformly. The client should (a) be easy to extend to other protocols. (b) be a standalone client and be integrable with Kamaelia’s other components, and (c) present a single interface for messaging across all protocols supported. An AIM user Jane messaging an IRC user Bob should not have to be aware (after the initial setup) that Bob is using a different protocol. All Jane should know is that she is sending messages and receiving messages back.

Currently, Beagle uses an XML-based interface over Unix sockets for it's communication. Specifically, clients talk to the Beagle daemon (beagled) with messages to (a) index data, and (b) perform queries using this interface. This project aims to use the search interface defined in the Xesam [1] specification over the D-Bus [2] message bus system.

[1] http://wiki.freedesktop.org/wiki/XesamAbout
[2] http://www.freedesktop.org/wiki/Software/dbus

The advantage of such a system is that if each desktop search application, such as Beagle [3] or Tracker [4] supports this interface, then client applications do not need to write code to support each search backend that it wishes to support.

[3] http://beagle-project.org/
[4] http://www.gnome.org/projects/tracker/index.html

Additionally, it is also desirable to see if such an interface would provide performance benefits over the current XML-over-Unix interface, in which case it could also serve as a replacement to the existing system.

Besides this, the project also includes improvements to the TextCache system (used to store partial text from documents for generating "snippets"), particularly with respect to the amount of disk space used.

The objective is to rewrite the Thunderbird backend to make it more efficient in every way possible. Straightening out various bugs will also be of highest priority. To make the integration between beagle and Thunderbird more apparent, an extension will be written for Thunderbird so beagle-search can open emails and contacts directly in Thunderbird.

This proposal is to implement deep shadow maps, including mipmapping, motion blur, colored shadows and filtering, in Blender. Also, a generic disk cache mechanism will be implemented.

Deep shadow maps are an advanced technique to make high-quality shadows. They work by storing additional samples and transparency info inside of the shadows, allowing for advanced techniques such as mipmapping and motion blur to be applied to shadow maps.

Since deep shadow maps take a great deal of memory, a generic tiling disk cache will also be implemented. This system will simply swap shadow map tiles to disk as needed to keep RAM consumption below a user-defined limit.

The main purpose is to remove every other sound code references from lender source than SoundSystem library.
The other task is removing unneccessary dependencies (fmod, openal) from SoundSystem code with keeping API unchanged.
The only used library is SDL, because it`s good multiplatform support. Openal will be replaced with verse project`s audio system code (code is available in verse blender source).

Blender is a powerful Free Software application for 3D modelling, animation, rendering, post-production, interactive creation and playback.

The aplication features many unique and expressive tools for 3D artists like the node-based material editor and compositor, integrated multi-resolution sculpting tools, multi-layer UV mapping and render baking and integrated video sequencing.

This project's goals are: to implement support for improving Blender's current material display in the 3D View window, using GLSL programmable hardware shaders; extend Blender's 3D View real-time material preview to support node-based materials by implementing a system to combine shader fragments that represent each node of the graph at real-time and, from those fragments, generate GLSL shaders; create a GLSL shaders representation for Blender's material nodes.

Further objectives, if the remaining time allows are: to create a generic GLSL shader node, allowing users to create their own shader in Blender's Text Editor window; to allow to import/export GLSL code for a material node network and to integrate it with Blender's scripting system and the forthcoming PyNodes API.

Tools to create beveled edges are very important in technical modelling and rendering. However, it is also important that the artist have as much control over the process as possible. During modelling, the artist should be able to bevel selected faces/edges/vertices, choose the appropriate beveling method, and accurately set and view the final result in real-time. Also, a mesh-wide technique for producing a beveled result would be very helpful, mainly for rendering. This would be best implemented as a modifier with options to bevel based on edge crease values, vertex weights, and percentages (based on face joining angles and face area sizes).

In addition, based on the fact that there is a shared interest and perhaps even similar algorithms, the creation of a parallel offset tool would be a great benefit to technical modelling. A parallel offset tool increases or decreases the area/volume of a mesh while attempting to keep the points on the resulting surface as equidistant as possible to the original surface.

This proposal discusses two additions to the Boost Graph library: the implementation of user-friendly, general purpose classes for simple directed and undirected graphs, and the implementaiton of several graph measures. Specifically, the graph classes are provided to improve the usability of Boost.Graph by providing implementations of common cases (hence lowering the entry barrier). The development of different graph measures can provide statistical insight into the structure of arbitrary graphs. These statistics may be used to help choose, at runtime, more efficient algorithms depending the traits of those graphs.

This proposal is for an extensible CGI library for C++. Despite C++ being historically regarded as somewhat 'overkill' for CGI programming, the language can in fact provide efficient, elegant and flexible solutions to many problems in the web application domain. With CGI programming unwaveringly popular and the scale and complexity of web programs ever increasing, there is a distinct need for a library to aid developing these programs using C++.

Furthermore, alternative implementations of CGI, such as FastCGI and SCGI – which significantly aid writing scalable CGI programs – have very poor support in C++, something the proposed library aims to remedy. The Boost libraries (esp. Boost.Asio) are fundamental to this library's design as it exists now (essentially as an incomplete FastCGI library).

The scope of the library is intentionally limited to CGI-specific functionality in order to avoid controversy (for instance, no html output formatting such as in perl's CGI.pm). It is also intended to be protocol-independent. That is, to allow a program to be written as a CGI program and for it to be allowed to run as a FastCGI program, for example, with only trivial alterations.

Take the following 'Hello world' example:

int main()
{
  cgi::request req; // initialise the environment, as one would expect
  req.header("Content-type: text/plain");
  req<< "Hello, world";
  return 0;
}

The above is a complete CGI program. The proposed library will ship with FastCGI and (possibly) SCGI drivers - provisionally called 'services' - as well as a standard CGI service. The following is a complete FastCGI program, which will handle multiple requests synchronously (ie. removing process startup/shutdown costs):

int main()
{ // Note: syntax is not final
  cgi::fcgi_service service;

  cgi::request req(service); // this works just like a standard cgi request object
  while( req.accept() ) {
    req.header("Content-type: text/plain");
    req<< "Hello, world";
  }
  return 0;
}

The above follows the style of the FastCGI reference library, although more responsive and realistic variations of the above are planned (and partly implemented already). These variations will aim to take full advantage of modern C++ techniques.

More information can be found at http://cgi.sf.net
I can be contacted directly at lists.drrngrvy [ @ ] googlemail [.] com

The Signal Network library aims to facilitate the implementation and interconnection of objects into signal networks using Boost.Signals. To understand the concept of signals (data generators / senders) and slots (data consumers / receivers), please see the Boost.Signals documentation and the associated tutorial.

This is a proposal for development of the Signal Network library as a part of Google Summer of Code and evential inclusion into Boost. Depending on what is preferred, the Signal Network library can be included into Boost.Signals or considered as a separate library.

The Signal Network library is to provide

    * a concise operator based syntax that facilitates construction and readiblity of signal networks
    * mechanisms that facilitate construction of signal network components
    * implemented building-block components that are applicable to a wide range of signal networks
    * detailed documentation (tutorial, examples and reference) of all of the above

The development platforms are

    * OS X / Xcode with Apple's branch of GCC
    * Windows / MSVC8.0

As a species, humans gather a majority of their input visually. However, there are an unlimited number of problems that programmers face on a day-to-day basis with computers of a numerical nature. Graphs are the best bridge between the two worlds: they allow for a quick and logical visualization of numerical data that humans are able to quickly comprehend. However, the C++/STL library does not provide a quick and easy way for a visualization of numerical data to occur, and neither does Boost. I propose writing a minimal SVG class that can write in the SVG format along with helper functions to help users visualize data stored in arrays as well as common STL containers. There will also be a subclass, svg_plot, that acts as a user interface for the graph data. The user will be able to customize how they would like the graph to be styled, and the data to be displayed.

The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts.

My proposal has two parts:

- Bring Boost.Extensions [1] to completion and enhance it.

As I will say in the next sections, I wanted to add to Boost a library that allows an application to have dynamic plugins/extensions within an infrastructure.

A member of the Boost mailing list told me about a library by Jeremy Pack called Extension. Jeremy and I agreed that the best approach would be to complete and enhance this library. In short, the
completion consists in preparing the library to be sent for review in Boost. The enhancements are several, and will be described later.

- Implement Reflection [2] using Extensions functionality

The Extensions functionality is the perfect platform to implement Reflection in C++. I've analyzed several papers about this topic and having Extensions complete will be great to start building this new
features. Also, the Boost Community showed a great interest saying that it would be a great addition to Boost. Discussing Reflection with Jeremy we agreed that it could be very useful to use the dynamic (run-time) method loading features in Extensions to give reflection functionality to normal C++ classes. I'll detail this
point later.

At the time of this writing, there does not exist a graphical BZFlag world map editor that supports all extensions defined by the BZW 2.0 format. While some existing editors come close, it is usually the case that they (a) do not fully support 'phydrv,' 'define,' 'group,' etc., (b) require the users to have a programmer's understanding of the file format to make use of all of its features, (c) are not well documented, or (d) are obsolete. This is problematic to the BZFlag community in that it hinders less technically-inclined users from developing worlds that make use of the BZW 2.0 features, or even developing worlds at all. To increase the world developer base, a new BZW editor needs to be created. It should allow users to quickly create worlds in a visual manner, provide GUIs to easily manipulate all features of BZW 2.0, provide intuitive, interactive visualizations of all of BZW 2.0's data, and allow for easy extendibility to ensure future BZW compatibility. Additionally, to encompass a larger user base, it will be developed using cross-platform toolkits, allowing it to be easily ported between operating systems and ideally support the same target operating systems as BZFlag itself.

Even the best game gets boring when it runs out of content. The traditional solution for that is creating a community of modders/map developers. This solution tough has it's weaknesses. The other solution is random map generation.

Random map generation is older than most players think. It probably started with the game Rogue, from which it wandered into the roguelike community. These in turn spawned one of the most popular games in history - Diablo.

Although BZFlag implements a poor man's random map generator as default, most players prefer to play on user made maps. The reason is simple -- the primitive scattering algorithm implemented in BZF's random map generation is neither good looking, nor interesting gameplay wise. Yet creating a nice looking and fun to play map by hand is a non-trivial task. To really enjoy playing BZFlag you need to search for good levels in the community, and even those get boring after a while because you learn their layout. Moreover, players who know the map well have an unfair advantage when playing against people who see the map for the first time.

Hence my idea of providing a complex and state of the art random map generation plugin for BZFlag, that will generate good-looking AND exciting/challenging levels to play. Additionally it will be based on a big set of parameters allowing the creation of pre-prepared generator data for different flavors of levels, or user defined generation. The goal is to provide a map system of near-infinite replayability.

I propose to develop a headless AI agent for BZFlag.
The main feature is that it will expose a 100% RoboCode API to loaded java source, meaning it will take advantage of already created RoboCode AIs.

The implementation will happen in 5 phases:
 - Phase 1: Rip out GUI code
   ~2 weeks
 - Phase 2: Implement Java support, enhance console/administration support
   ~2 weeks
 - Phase 3: Implement full support for RoboCode API, expand it (still backwards compatible) to support BZF-specific features (e.g. jumping).
   ~4 weeks
 - Phase 4: Bug fixing
   N/A
 - Phase 5: Safety net
   ~4 weeks

Deliverables:
 - Fully headless client.
 - 100% support for RoboCode API.
 - BZFlag specific extensions of the RoboCode API.
 - CLI/text-based administration.
Potential deliverables:
 - Support for other languages (using SWIG).
 - Remote administration (telnet?).
 - Extensions to the RoboCode API to support chat.
 - Configuration files (instead of commandline arguments).

See the detailed description for the details on the implementation.

The goal of the project is to bring the wonderful world of friendly distributed version control to Visual Studio 2005.

The project's deliverables are a class library written in C# exposing bzrlib to all .NET languages running with Mono or Microsoft's .NET, and a Visual Studio source control provider based of that library integrating Bazaar into Visual Studio 2005. The library could easily be reused to integrate Bazaar also into other IDEs like MonoDevelop.

Seamless Visual Studio integration could be a great selling point to attract users of other version control systems for migrating to Bazaar.

IP issues are becoming critical in all areas. Adobe has recognized that by developing XMP platform. Creative Commons is an important way of adding IP licensing information to a document's metadata. Despite being a requested feature for OpenOffice.org for more than two years, nothing has materialized. [http://www.openoffice.org/issues/show_bug.cgi?id=66656 filed in June 2006; http://www.openoffice.org/issues/show_bug.cgi?id=29404 filed in May 2004]. We can't wait anymore. The goal of this project is to provide a tool for supporting the process of licensing documents. Microsoft Office has a Creative Commons plug-in to put IP metadata in its documents. I propose a similar Creative Commons add-in for OpenOffice.org that would allow license information to be embedded in OpenOffice.org documents. [http://www.openoffice.org/issues/show_bug.cgi?id=29404 is an example of one way this tool could be used.] Having a simple way to add Creative Commons licenses will help to spread those licenses much more broadly.

Working under Creative Commons, I will extended the Tracker search and indexing engine to support the extraction of license claims. Because of the various forms that the license may take, I will build support based on the recommendations of Creative Commons, as outlined at http://creativecommons.org/technology/usingmarkup. If possible, I will discuss and extend these recommendations for new formats.

The project will have two parts 1) Extracting the license claims from a variety of formats, and 2) Indexing the license claims in a consistent form, providing users the ability to search for works based on their license.

In addition to indexing license claims, other metadata can also be indexed. For example, because XMP is a format for arbitrary metadata, metadata not related to licenses will also be made available; rather than ignoring this extra information, it could also be indexed as appropriate or made available for indexing in the future. In other words, I will extend Tracker in the process of indexing license claims. Specifically, I will also add the ability for Tracker to read XMP sidecar files. At the very least, the project will result in Tracker gaining support for indexing license claims embedding in MP3, OGG, PDF, HTML, and XML formats.

Revamp all CLAM SMS transformations. Turn real-time all those still aren't and have them working on Network Editor. For example: Harmonizer, Morph and Time Stretch. Make nice prototypes for use them with Prototyper and have special focus on some. Also make real-time Voice2Midi and all those widgets which can be needed.

CLAM provides a dynamic and intuitive way to interact with audio plugins and generate some results.

This projects aims to bring together some audio plugin standards that exists in the present and make them available for the CLAM networks. And also to provide the ability to treat a CLAM network as a standard plugin.

Moreover, it also will provide a generic interface for all kind of plugins in order to manage and provide more detailed information of them.

More can be found here: http://iua-share.upf.edu/wikis/clam/index.php/Devel/Plugins_TODOs

Modern software-based musical instruments tend to be centered around the keyboard paradigm in which sound synthesis is controlled merely by discrete pitch and amplitude values. This paucity of information, however, places severe limits on the kinds of music that can be made with such instruments, and for this reason the term “electronic music” has become synonymous with different styles of dance music. I propose to create a real-time synthesizer that can be controlled by continuous values for pitch, amplitude and brightness. This project would be realized using the CLAM library for audio analysis and synthesis and would further the goals of this project by providing an example application illustrating the use of spectral modeling synthesis. Spectral modeling synthesis is a variety of sound synthesis that is particularly well suited to the stated task, because it creates models of recorded sounds which can be manipulated in interesting ways without noticeable loss of sound quality.

In the first stage of the project, I will create a database of samples to be used by the synthesizer. I will make recordings of an ebow playing a guitar string with pitches at different levels of amplitude and brightness. (An ebow is a device which creates a magnetic field which can be used to make steel strings vibrate.) I will derive spectral models of these recordings using CLAM’s SMSTool, and I will save segments of these recordings with uniform parameter values in SDIF format.

In the second stage I will design the database for managing these SDIF files. It will allow clients to query the database using values for pitch, loudness and brightness and retrieve in real-time the best fitting segment for a given set of query values. Due to the requirement of real-time processing, the database will likely have to make use of either caching or sample pre-loading.

In the third stage I will design the synthesis engine that will be responsible for interpolating between segments and resynthesizing the audio from its spectral representation. Given the nature of the sound source, it is possible that a sinusoidal model will give an adequate representation of the sonic material, and therefore, the complexities of resynthesizing the residual portion of the signal can be avoided. I assume that this would be preferable as one of the goals of this project is to create a simpler, more understandable version of a previous CLAM project named SALTO which performed a full-blown sinusoid plus residual resynthesis of saxophone recordings.

This application will detail my interests in the CLAM project and
explain what I can offer the project as a participant in the summer of
code. My main interest is in speech processing and recognition. This
gives me a partial overlap in interests in the audio processing
capabilities of CLAM, as well as other interests that could add to
CLAM's capabilities and user base. Specifically, I am familiar with
many of the DSP techniques used in CLAM, but with more of an emphasis
on speech than music. This slight difference in focus applies both at
the DSP level, as well as the user interface level, since linguists
and speech scientists have different needs from a user interface as
well as the DSP behind it: at the DSP level, there are warpings to the
spectrum to simulate the auditory system, and the LPC model is based
on an articulatory model, for example, and at the user interface
level, there are certain displays that linguistics prefer, like black
and white spectrograms and multi-tiered transcriptions, to name a few.
Given my background in linguistics (BA), computer science (MS, working
on PhD), and EE/signal processing (2 speech processing courses), the
project idea that I am most interested in is the vowel synthesizer .
Below in the detailed description I will explain my past experience
building a LPC/source-filter based vowel synthesizer in Matlab for my
speech processing class. I'll also explain other ideas I have, both
to further develop this project, and other ideas I have for
incorporating speech recognition abilities into CLAM, such as singing
synthesis, . I will also describe facilities available to me at my
university that may be helpful.

I will improve chord extraction in CLAM (C++ Library for Audio and Music) for real-time usage. Before the start of the summer, as part of my studies, I will perform research on the current state of this specific area of audio digital signal processing. Then I will try to compare the most promising algorithms by implementing them in CLAM. I will also try to improve the visualization of the results. As a by-product of the research phase I would also like to explore the possibility of adding instrument recognition in the future.

The SwingX builder will be an extension to the Swingbuilder class currently included in Groovy. More and more applications are using the SwingLabs components in production applications. Although one is able to use the SwingX components in Groovy using Java code, this means is verbose compared to the SwingBuilder and very un-Groovy.

Castor is a pretty cool XML and database binding framework. Currently it lacks an implementation of the Sun JAXB2 standard and I want to help to implement it on top of todays Castor implementation.

There are a lot of very interesting details at implementing JAXB2 for Castor:
Today Castor itself can run under Java 1.3.1, 1.4.2 and 1.5.0 - but JAXB2 will required Java 1.5.0 features to be used in the heart of Castor (at un-/marshalling) - so Castor will need to get more 'plugable'
Castor already has a defined and approved XML - Java mapping, how to implement the JAXB style as a second possibility without harming existing installations
A source generator from schema to Java exists, but it doesn't support classes with annotations - the new implementation needs to generate annotated Java
Today, mapping information can be provided in a variety of possibilities but not via Java annotations - the extensions will allow that mapping information is read from Java annotations
A possibility to generate a schema definition from Java classes needs to be introduced.
The bindings definition of JAXB needs to be supported by schema compiler.
The JAXB API specification needs to be supported

The implementation of JAXB2 for Castor will be a Java project which results in an own library on top of Castor. Castor libraries are used by the 'JAXB2 for Castor' implementation which just provides the new implementation for users which want to rely on the standard. In addition Castor itself will also need to be modified to support features the JAXB standard requires either by implementing them in Castor itself or by providing the possibility to plugin JAXB specific algorithms.

Coppermine as I see it today is implemented in PHP and most of its application logic resides at the server. Also, Coppermine is basically a user application and derives its USP from user experience and the easy of use. However, given the advent of new technologies such as Javascript and AJAX, I strongly feel that the front-end of Coppermine can be greatly improved to provide a far better user experience. Another major advantage of client-side operations is that the load on the server decreases drastically, since the client browser does most of the layout processing, while the server merely acts as a query engine. Examples of improvements possible through Javascript/AJAX are:
(1) The whole page does not have to be reloaded when one moves from one picture to the next picture in the same gallery.
(2) Predictive caching of pictures can be done so that the user does not even have to wait for the next picture and therefore save her browsing time.
(3) In the forums area and the comments section of pictures, the entire page does not refresh when a comment is added or modified. All operations are handled asynchronously.

The integration of client-side operations into Coppermine would require the client to query/ call functions on the server directly, and therefore, would allow the development of a comprehensive API to interface with Coppermine, which can then be wrapped around any other programming language (including Java, GTK). This can be visualized by say creating a server module to upload pictures, which is called by Javascript through AJAX. This server module is basically providing an API to the outside world to interface with Coppermine - infact, it allows remote interfacing from any web service or application.

My proposal entails the development of an API for Coppermine, and instead of the development of a GTK client for it, develop an interface for the same through AJAX and Javascript, so as to allow a smooth experience to the users of the application.

I would like to develop the ability of users creating albums in admin allowed categories.

I am using coppermine for about 3 years now, and it think it is time for me to contribute to the project.

Overview
--------
JCpg is a java based application which allows a Coppermine Photo Gallery (Cpg) user to manage his photos offline. When an internet connection is established, the program will automatically synchronise the galleries.

It will be possible for a user to offline manage galleries, albums, photocollections and even do some basic photo editing.

It would be very handy for people to be able to do this kind of management everywhere they are, even when no internet connection is available. Using Java, the user will even be able to run the application on all of his operation systems with just one version.

Used technologies and protocols:
• I will either use Swing or SWT for the creation of the GUI. I read a lot of articles comparing both technologies and I’m not convinced that SWT is faster than Swing but SWT is more easy to use.
• For the datatransmissions and folder settings I will use the FTP protocol.
• The Java API to communicate with the user’s SQL databse.
• Java 1.5.0 or Java 1.6.0. This depends on when Apple will release the JDK 6 for OS X.

Main features in first stage:
• managing galleries
• managing albums
• managing photocollections
• basic photo editing

Goals in the first stage:
• learning more about Swing and SWT to make the GUI not Java standard (grey).
• learning more about network programming in Java.
• making a better and more userfriendly gallery management script of Cpg.
• deliver JCpg V1.0.

Links
----
Tracker: http://ardella.madoka.be/jcpg

I will add three features to the Coppermine photo gallery system. All focus on separate areas of the system but are all united in improving user experience and overall functionality of the system.

I will create the ability to export the gallery into a format that is useful for offline viewing. I will allow the person exporting the ability to select specific albums or the entire gallery to export. Also, since this feature may be used for many different purposes, I will create the option to export the albums in multiple formatted html files, or as a directory structure mirroring the categories and albums containing the image files alone, useful for backing up the data of a Coppermine gallery, printing large quantities of photos, creating a slideshow, and countless other uses.

Secondly I would like to add photo tagging support to the Coppermine photo gallery system. Coppermine already supports assigning keywords to photos, and allows for searching based on keyword. However, keywords can be cumbersome when used to identify people in photos. I would like to provide a way for users to 'tag' specific parts of a photo (as is available on several web photo gallery services), such as a person or thing, and users to search the gallery by tags and have an optional 'tagcloud' for these tags possibly integrated with the keywords ‘tagcloud’.

Finally, I would like to improve the search function. I will add support for searching album titles and categories. In addition I would add the ability of the search to handle string queries enclosed in quotes such as, “George Washington” (as most major search engines handle queries). Time permitting I will also add an advanced search option with more search methods including regular expressions.

All three of these improvements will lead to a general increase in user experience of those visiting Coppermine powered galleries, and open up coppermine powered galleries to uncountable uses off-line.

Currently, a lot of people are willing to install LinuxBIOS in theirs motherboards, but there is two main problems:
* LinuxBIOS is not supported by all motherboards;
* The installation process is very complex.

The first problem will be fixed soon since the motherboard manufactures become interested in LinuxBIOS. Since LinuxBIOS has a lot of advantages when compared to tradicional BIOSes, we believe that users are the main piece in this process, claiming for motherboards with LinuxBIOS support. Companies that depends on more powerful BIOSes or need to make some custom BIOS may help in this process as well.
But the other problem remains.

My proposal is to develop a software solution that will solve the second problem. This tool will help end users creating a LinuxBIOS distro to flashes on theirs motherboards. Nowadays, the process to create a LinuxBIOS and root file system is painful. Until it works, tons of compilation and waste of time with tests are necessary.

The software will supply a menu based interface so that users can choose between applications and features to be integrated with LinuxBIOS.

This project consists of implementing an efficient way of booting Windows Vista/XP/2003 under LinuxBIOS. Three different approaches have been suggested: using a dedicated LinuxBIOS loader, using kexec/kboot or fixing ADLO (Add-on layer). When choosing one of these, I will take into
consideration the one which, besides supporting Windows XP, can be easily adapted to support windows vista and its possible future modifications.

The LinuxBIOS project has been gaining momentum in recent years. More and more platforms implement LinuxBIOS as their core firmware; replacing the more conventional BIOS from vendors such as Award-Phoenix,Inc. and American Megatrends (AMI). Nonetheless, it lacks Windows-based utility to flash the BIOS binary to the motherboard flash ROM because LinuxBIOS development mainly conducted within Linux operating system.
  In order to bring LinuxBIOS into a wider audience, it’s important to port some of its components to Windows especially the BIOS flashing utility. This utility is named Flashrom within the LinuxBIOS code base. The nature of a BIOS flashing utility is to gain direct access to the hardware. Therefore, it’s important to port such a utility due to the fact that it can not be executed reliably within virtual machine such as VMware.
        Porting Flashrom to windows will benefit many Windows-based firmware developers and any system programmers familiar with Windows-based software development but not experienced enough in Linux-based software development. Winflashrom seeks to become the windows-port of the Flashrom utility within the LinuxBIOS project. It will support both console-based interface and a GUI.
        Winflashrom will be composed of a Windows kernel-mode driver interface and a user-mode application that interacts with the kernel-mode driver. The kernel mode driver provides direct access to the BIOS flash ROM chip and other relevant chips in the motherboard, while the user-mode application provides the console interface and the GUI. A completed Winflashrom would certainly help the development of Windows support in LinuxBIOS as a whole because it provides a “direct link” between Windows and the BIOS binary produced by the LinuxBIOS project.

I have some experience with Forth and Open Firmware and would love to work on making Linuxbios work with the available open source implementations of open firmware like the OLPC implementation, SLOF, etc.

I propose to work on two milestones:

1. Get Grub2 to run as LinuxBIOS payload
This combination enables very flexible booting right from the flashrom, with support for several filesystems and executable formats.
Given that grub2 can be expected to become a de-facto standard in the open source operating system area, this work opens the door to wider LinuxBIOS deployment.

While working on this, I will port both projects to Solaris, where necessary.

I expect this milestone to take 3-4 weeks


2. Build a configuration editor for LinuxBIOS 3
Currently, configuring LinuxBIOS3 involves writing a file by hand which defines the properties of the hardware and the firmware that should be built for it.
The goal of this milestone is a java based editor to create this configfile. It will be based on Swing or AWT and should also support the user beyond syntax issues, by providing building blocks (eg. known combinations as provided by chipsets) and janitorial checks for potential issues, warning the user.
Such a tool would help mainboard vendors a lot with supporting their combination of chipsets, and I'm not sure that there are similar highlevel tools available for other BIOS systems.
It could be used as webapplet for a remote firmware building service, if there is interest in that.

I expect that I can provide a working editor by the end of the SoC period, but can't give a definite schedule without detailed discussion about the feature set.


If these two milestones don't fill the 3 months, I would work on whatever the mentors think is interesting.
One thing that I would consider interesting is building more payloads, like one for OpenFirmware support.

(U)EFI shares a significant market in the firmware area. It is absolutely necessary to get the (U)EFI implementation to work as the LinuxBIOS payload. There are two open source (U)EFI implementation, GNUFI and TianoCore. The former is still in the development progress and there is no official release till now. And the TianoCore is comparatively stable, even the EDKII of TianoCore supports the gnu tool-chain for building. I will introduce the feature that an (U)EFI implementation runs as the LinuxBIOS payload referring to the TianoCore. The following tasks are needed for this goal in general:
1. To figure out the platform/hardware dependent module and the platform/hardware independent modules in the TianoCore, and the interfaces between them.
2. To figure out the rules/methods/interfaces that how the payload and the LinuxBIOS interoperate.
3. To develop the new module of LinuxBIOS to replace the platform/hardware dependent module of TianCore. Specifically to encapsulate the original module of LinuxBIOS to form the new interfaces to support the EDK foundation source codes.
4. To develop the new interfaces for the interoperation between the EFI payload and LinuxBIOS
Maybe the 3rd and 4th tasks can be unified together when complete the 2nd task.

Crystal Space, being a 3d engine, deserves a good art pipeline so that applications using it can focus on creating assets, not editing world files by hand. Having worked on several game projects using CS over the past 2 years, I have experienced directly the difficulty of getting art into the engine. I would like to help take a huge step in improving it by creating a usable world editor.

The editor should have a completed framework by the end of the work period, including a working plugin system, undo/redo system, selection system, tool system, save/load functionality, scene browser, factory browser, and property editor. Also, basic selection and transform tools will be implemented. Any remaining time will be used to polish the user interface or implement tools for other CS features, such as terrain.

COLLADA is a 3D computer graphics digital asset schema [1]. It is a file format description designed with computer gaming and interactive applications in mind. The major function of the schema is to provide the necessary tools so that applications can easily, efficiently, and dynamically share media and digital assets. The primary goal of this project is to develop and implement an importer for the Crystal Space 3D SDK such that it can use files created in the COLLADA schema.

Artificial Intelligence Module

The project which I propose tries to cover to basic actual needs of the Crystal Space projects, AI and path finding (which I would include within the AI module). A good AI module would be a great step to the project since it is (in my opinion) a critical part of any serious game engine.

I wish to create a complete, solid, AI module that could be useful to many projects with small or medium demands on AI and physics. I also wish to leave very good documentation on my achievements so there could be further advancements within the same projects (even by myself if that's possible).

The current code-base in CrystalSpace has critical code paths optimized mainly by choice of algorithm and in some cases in the implementation; however this is in pure C++. In most cases this is okay or even as good as we will get, but there are a number of places where we could benefit from correct usage of platform specific optimizations such as SSE on Intel and AltiVec on PPC. As the code is generally platform independent and supports a wide range of hardware this poses a number of challenges when it comes to abstraction and using the right implementation.

This project would develop a framework within which platform specific routines can be developed for critical code, and a right set of routines be selected both during compile and at runtime, determined by CPU feature set and target OS support. As a sort of "proof-of-concept", it would also optimize one or more chosen places to use this framework.

Scientists that model complex systems on the computer often need to perform hundreds or thousands of simulation runs using different parameters. Modern grid computing systems have the potential to make such batches of simulations very easy, but no widely available software exists to integrate the two. GridSweeper, an open-source project begun during Summer of Code 2006, will provide scientists with a straightforward interface for running simulation batches. Some work remains before the software is useful and complete. This year's project is to complete that work.

The GridSweeper code currently includes support for several kinds of parameter sweeps, including simple lists, ranges, stochastic sampling, and arbitrary combinations thereof. Code also exists to extend GridSweeper with adapter plug-ins for different kinds of model programs, and with plug-ins to provide support for different file transfer systems. Job submission is done via the Distributed Resource Management Application API (DRMAA).

This year's project will add more sophisticated user interfaces, allowing the user to create, modify, and save batches from the command-line or from a graphical interface. It will also include several plug-ins for different types of model programs. Finally, the project will include testing, documentation, and packaging of the GridSweeper project.

The original 2006 proposal is available here:

http://code.edbaskerville.com/gridsweeper/proposal.html

and development progress is being tracked here:

http://code.edbaskerville.com/

The primary benefits of I-SPOC are likely to be derived from its facilitation of accessibility, organization, and communication. Models must be easily downloaded and cross-linked with results/literature. Models must also easily be organized into multiple taxonomies, such as discipline(s), methodology (ABM/GA/CA), and qualitative focus (equilibrium/non-equilibrium). Lastly, and perhaps most importantly, communication both specific to single models and in general should be as easy as possible, while still providing for features such as LaTeX typesetting. In order to most effectively accomplish these objectives, I propose the implementation of a Drupal site.

To provide for the modeling side, a critical mass of basic models should be developed to both attract and sustain interest in the project. I propose the implementation of a number of archetypal models in each of the major disciplines (social dynamics, biology, economics, physics, political science), as well as an active attempt to engage authors of recently published modeling material (e.g. arxiv,SSRN,RePeC) in the process.

I would create some initial SPOCs and MOREs as proposed on your ideas page. Not only complex systems models like the tribute system and landscape theory described in Axelrod's books, but also nonlinear physical systems such as a 3-body problem or free pendulum; I believe including example SPOCs beyond the scope of complex systems will increase the cross-disciplinary appeal of the I-SPOC project since academics from fields like physics, applied mathematics, chemistry etc. are also relying more heavily on computation, though not
all such code is necessarily related to complex systems analysis.

It is important that prototype SPOCs contain code in a number of different languages (Java, C, Matlab, Python...) possibly even the
same code in different languages; one of your stated goals is replication and re-implementation, and having example SPOCs with code in different languages will help back it up.

As researchers study more and more complex systems, the theories they generate become more and more complex. This has led to the rise of computational modeling as a method for investigating and understanding such systems. However, computational modeling research produces results that are not well suited to the standard academic publication format. Researchers need to be able to experience models created by other researchers, and need to be able to expand on and modify them, looking at different situations or changing them in new ways. This cannot be done via a high-level summary of by the model and the results found within a static publication.

There have been a number of suggestions to resolve this problem, including one by Humphreys & O'Leary (2002) that every modeler should set up a version of their model on a publicly accessible computer, so that other researchers could log in and use the model. Instead of taking this approach, the I-SPOC proposal from the Center for the Study of Complex System is to form an online repository where models and their associated papers and data can be stored, along with instructions for running and using these models, and any links to newer, older, or similar models can be kept track of. This allows for a simple, direct way to get access to the work of other researchers, allowing for greater collaboration, and more comparisons between models and expansions of existing models. This also opens up the possibility of testing models, which is especially important considering Axelrod's finding that when attempting to replicate models, there is consistent “ambiguity in the published descriptions, ... gaps in the published descriptions, ... [and] situations in which the published description was clear, but wrong” (Axelrod, 2003).

This proposal is to build an online repository system following the requirements described in
http://www.cscs.umich.edu/~rlr/SoC/uploads/Main/SPOC-Description-From-2007-11-12.pdf
This will allow for the submission and updating of these SPOCs (Scientific Paper with Open Communication). Important features include version control for tracking changes over time, feedback on issues involved in installing and running models, and links to other related models. The intent is to allow computational models to be a rigorous, reproducible, and easily accessible aspect of modern scientific research.

The proposal is for the development of a mathematical model,methods, and libraries to analyze Urban design, as well as patterns of Urban growth and various feature associated with it using MASON. Primary deliverable will be the model along with the system as a library which would make modeling of urban space and its elements easy for future analysis in the field of Computer Aided Urban Design/ Analysis.

        The urban system is an intrinsically dynamic environment – a constant struggle for equilibrium between constraints & requirements, a platform where diverse interactions take place between agents of numerous but finite variety. The constraints maybe dynamic or static. The requirements are a constantly changing set which is often dependent on the present situation thus inducing the concept of feedback. Such a system of agents – who provide constraints and requirements in a heterogeneous & dynamic environment with a constant feedback system could be interpreted as a complex system. Hence urban system needs to be interpreted and analyzed using mathematical methods and techniques in the field of complex system analysis.

Application of such a multi-agent based approach in the field of Urban development provides an opportunity to look at urban growth patterns, profile and form in a completely new light. Drawing analogies from the functioning of Urban System as interactions in a multi-agent environment, a simulation of the same can be used to develop solutions for the Urban Design problem.

The goal of the "HTML diff" project is to provide a Java library that compares XML files. The minimum inputs are 2 XML files, and the minimum output file is a Java representation of the basic operations that turned the first data structure into the second. This output can be converted to an XML-based representation or, given the proper formatting guidelines into an html file with a certain syntax to denote changes.
In addition, distance metrics can be computed that allow the user to quantify by how much 2 files differ. This enables them to distinguish minor from major changes, and tells them what the (chronological) relationships are between 3 files.

My application is about implementing Mole:

http://wiki.debian.org/Mole

Mole is a set of scripts, mostly in python, to manage many kinds of
information. Although designed with Debian QA purposes and goals in mind, this
could also find many other uses, being pretty generic infrastructure.

Mole provides at least the following:
- A means to accept submitted information, with optional access control and
  moderation
- A means to store both transient and constant information ("data")
- A means to retrieve this information quickly and efficiently in both
  micro-queries and as whole datasets, including easy mirroring
- A web interface for easy browsing of the available information
- A means to coordinate the generation of information

This is very generally spoken mole. To make things a bit more concrete, one
example:

- Mole would accept (by mail, HTTP post, or otherwise) build logs for building
  source package in current unstable/testing in a standard or rather a
  specifically tweaked environment
- It would store it in its database in an efficient form, keeping some
  configured amount of older versions too
- It would maintain a list of source packages that don't have such log yet, or
  which log is older than a configurable amount of time, and provide worker
  machines that can do such rebuilding with a todo-list. Mole would
  automatically keep track such that double work is prevented.
- Via for example a web interface people can query results of specific
  packages, but one can also retrieve the full database.

This approach is very powerful, because mole "jobs" can be stacked. To continue
with the above example, a different job could keep track of such logs that
didn't get 'judged' yet, and have a worker judge them for
"succesful/not-succesful", and store those qualifications in a result table.

Additionally, data-providers do not need to be computer programs, they can also
be humans. For example, the job could be "file bugs on failed logs/mark a
failed log as "wrongly failed". Data can also be abount non-package things,
such as bugs, or mirrors. It can itself also be something else than quality
tests, examples would be mere extraction of data such as .desktop files for
auto-installers, SLOC-counts for funny statistics, or (user-supplied)
screenshots and reviews.

When upgrading packages, especially between releases, it is possible for conflicts to occur as a result of dependency problems, version conflicts, and more. In order to identify these problems early, the overall goal of this project will be to create a system which runs an automated test upgrade and logs the results. It will do so by creating a Debian environment from scratch running within a QEMU virtual session. The initial environment will be built using packages from a selected repository, and within the live system it will then be upgraded using packages from a second repository. Problems encountered during this upgrade will be logged and reported in order that they can be fixed early or before official releases. This is often hard to do on live systems as it requires submitting the system to danger of a failed upgrade, and it requires having a system in the desired initial release version.
   In the final version I hope to include additional features such as selecting specific version of packages from each repository so that bug reports of package upgrade problems can use a list of installed packages to reproduce the problem and identify the causing element more easily. It could also be used for debugging in general if one wanted to easily reproduce the Debian system on which an ellusive bug occurs.
   This tool can be used by developers for the above reasons, and it could also be used by system administrators, as well, for the purpose of running it as a test before upgrading their live systems. In this way, administrators would be able to prevent a conflict from occurring the midst of an upgrade, and what's more notify Debian developers so that this problem can be resolved without leaving their existing system in a half-upgraded state.
   Furthermore, thanks to the versatility of QEMU, one would be able to test upgrades for many target CPU types including x86, x86_64, ARM, SPARC, PPC, and MIPS, all from an x86, x86_64, or PPC host system.

The goal of this project is to improve piuparts to help Debian's Quality Assurance efforts and make piuparts easier to use for Debian maintainers in order to spread its use to package checking.

This project will be to expand on the BitTorrent application to work
effectively with large, constantly updating collections of files
such as the Debian archive. BitTorrent is a peer-to-peer file
sharing application designed to reduce the costs of hardware,
hosting and bandwidth resources for the original distributor by
allowing downloading peers to share downloaded data with others.
This project proposes to create a backend or proxy to the Debian
package distribution tool apt, which will allow for the downloading
of packages from other users of Debian in a BitTorrent-like manner,
thus reducing the costs incurred by the archive's host.

Upon completion and widescale deployment of the service, the
bandwidth and hardware costs of providing a very large Debian
archive to hundreds of thousands of users will be dramatically
reduced.

Though the idea of implementing a BitTorrent-like solution to
package distribution seems good, there are some problems with the
current way that BitTorrent distributes files that make it
unsuitable for the Debian archive. First, the Debian archive is a
very large repository of packages, including many different versions
and architectures. A normal user will only want to download a very
small subset of the entire archive, whereas it is normal in
BitTorrent to download the entire torrent. Secondly, the archive is
made up of a distribution of file sizes, many of which are smaller
than the smallest piece size used by BitTorrent today. Some
enhancements will be needed to allow for the downloading of small
packages without wasting large amounts of bandwidth. Finally, the
archive is frequently updated, though only a very small portion of
it at a time. BitTorrent is currently not designed to handle updates
to files, nor multiple versions of files. Solutions to all of these
problems will need to be found.

More information is available here:

http://www.cs.sfu.ca/~camerond/personal/GoogleSoCDebian.html

The teams and maintainers responsible for big sets of packages in Debian, like X.Org, GNOME, KDE, Kernel, etc. frequently lack the manpower to keep their packages up-to-date and still triage all bugs reported against them. Usually, these teams are running up against huge backlogs of bug reports, and some reports may remain unanswered for a long period of time, which in turn may cause the reporting users to think their reports aren't useful, and stop to submit bugs. This loss of bug reports may lead to the reduction of the quality of the Debian distribution and of the upstream software, as a good amount of these bugs need only to be forwarded and fixed by the upstream developers. This was recently discussed in the debian-project mailling list [1].

To address this problem, I propose the development of a tool to facilitate the triaging of bug reports, rising the productivity of the limited time the maintainers have to triage the bugs and offering a friendly tool to make basic bug triaging an attractive way for users to introduce themselves in Free Software development.

[1] http://lists.debian.org/debian-devel/2007/02/msg00643.html

The Debian Project has its own Bug Tracking System (called debbugs, or just BTS), which includes many nice features, but one important drawback: it's driven completely by email. Lots of users and developers would benefit from the ability of being able to manipulate and submit bugs directly with a web interface.

The aim of this Summer of Code project is developing a web-interface for debbugs which is not read-only as the current one, but which enables manipulation of bugs both in form of new submissions and in form of all the other actions which are possible on previously reported bugs.

The project goal is to develop a technique for Debian-based clusters security status managment. Notwithstanding the presence of the tools providing local security updates checking (i.e. update-notifier, integrated with the GNOME desktop, or cron-apt), there is no essential way to manage tens or hundreds of systems.
 This project is based on Open Vulnerability and Assessment Language, which is an international information security community standard to promote open and publicly available security content, and to standardize the transfer of this information across the entire spectrum of security tools and services. OVAL includes a language for data definition and interpretator which collect information from a computer for testing, to evaluate and carry out the OVAL definitions for that platform, and to report the results of the tests.
 Only the generic implementation of OVAL agent is present to the moment, but it may be adapted for the Debian distribution. And implementation of OVAL server will provide centralized managment of the entrie network security status.

The Debian Project routinely builds CD and DVD images of specific distributions, like Debian stable, Debian testing and Debian unstable. Each one of those in different "flavours" that fit different needs (business card, net-inst, full archive) and for different target architectures [1]. Also there are images for various Custom Debian Distributions like Skolelinux, and even live-CD systems.

Many of those images are built weekly or even daily, this results in a *lot* of ISO files.

As verifying that the built images work is currently a manual process, there is too much work spent in this task. Also, images meant for a release need more presumption of correctness, as it would be very bad publicity to ship a broken image.

To alleviate this situation, a modular lintian-like CD-image testing tool is proposed.

[1] http://lists.debian.org/debian-cd/2006/12/msg00068.html

Live-helper is a utility to build CD, DVD, netboot and USB-stick live images of Debian, a GNU/Linux operating system. It boasts support for multiple architectures, auto-building images, amongst many other features.

Live-helper is extremely flexible, allowing interested parties to create their own system completely specific to their needs, including support for custom package lists, kernel parameters, encryption, additional commands to configure the live system etc.

My proposal is to construct a graphical user interface that can be used in conjunction with live-helper to build Debian Live systems, allowing editing of existing configurations and including a 'wizard'-style walkthrough for the first-time user.

Providing less experienced users with the opportunity to easily create live distributions will generate more exposure for live-helper, providing more valuable feedback for its developers and ultimately helping Debian's image as an extremely flexible and free operating system.

The GUI will be written in Python using the pygtk GTK+ bindings.

I propose to write a Logo interpreter for the TI-83 Plus and related
calculators. This will serve as an alternative programming
environment which is at once easy for beginners to learn and far more
powerful than the builtin "TI-BASIC" language used on these
calculators. I will aim for "pseudo-compatibility" with the popular
UCBLogo dialect, so that it will be possible, with some care, to run
the same programs on the PC and on the calculator. Although I will
not have time to implement the entire UCBLogo library in the course of
a summer, by the end of the summer I hope to have a functional
interpreter that can run some interesting programs.

There are several very useful applications for the TI-83+ series which make use of the system's hook facilities. However, most of these applications don't share hooks well together, or only share hooks with a few other programs. Hook Manager would make the hooks be fully under the user's control.

Several useful applications for the TI-83+ calculator series make use of the system's integrated hook facilities. Unfortunately, most of these applications will not share the hooks with other applications for the TI-83+, or if they do, only with a limited subset. The Hook Manager project seeks to create a program that places the user in full control of the system hooks.

Hook Manager would manage the system's hooks, allowing multiple applications' hooks to be chained together in any order specified by the user. These hooks would be detected from currently active hooks. An editor will allow the user to (de)activate and reorder hooks at any time.

I will implement a general method offering a public and private API for existing Django models. New generic views will simplify data retrieval and modification via different web services in a resource-centric REST architecture, providing model data in formats such as XML, JSON and YAML with very little custom code.

For further updates look at http://jannis.leidel.info and http://code.google.com/p/django-package/

Django is one of the major web frameworks that emerged within the last years and created a solid user and developer base. It simplifies the development process by providing tools to reduce repetition, abstracting common web paradigms and still being hackable. Until today that attracted a wide section of programmers, from novices to pros.

As the code base is constantly moving towards the 1.0 release, more and more people are using Django to build small projects and websites, just as well as commercial applications like intranet services and content managment systems are realized with it, too. Good for them:

  Reinventing the wheel with Django is perfectly easy – every Django beginner wrote a todo list or weblog applicaton :)

But this is not the end of the road for user participation. The community should be able to uncover more web ideas for contrib apps, combine the already written views and templates to more effecient apps and simply share their products with other users.

The implementation of a package system would lower the threshold for Django and Python beginners significantly because it reduces the hassle of the current installation procedure.

My task is to do the groundwork for an application which manages Django application packages and integrates tightly with the Django code.

* To implement check constraints on models.

The various check constraints to be implemented:
1)Range Based Check Constraints
2)Value Based Check Constraints
----------------------------------------------------------------------
Most Database engines like Postgresql, Sqlite, Firebird etc have built in support for check constraints. So for these database engines the check constraints can be implemented at the database level whereas for MySQL (which does not support check constraints),it has to be implemented at the application level (ie in Django).

Example 1: Range based Constraint

from django.contrib.constraints import CheckConstraints

class Product(models.Model):
  product_name = models.CharField(maxlength=50)
  discount = models.IntegerField()
  check_discount = CheckConstraints(discount__gte = 0 AND discount__lt = 100)
  price = models.IntegerField()
 check_price = CheckConstraints(price__between = [0,10000] AND price__gt = discount)


Discount and price can only be a non-negative value. Also it checks for discount < 100 and if price > discount and price is between 0 and 10,000.

The various Range based constraints being

 * greater than gt >
 * lesser than lt <
 * equal to eq =
 * not equal to neq <>
 * lesser than or equal to lte <=
 * greater than or equal to gte >=
 * between between (expects a range)

Range based constraints can be used to check for constraints for more than one column (as seen in the example above).

Example 2: Value Based Constraints

from django.contrib.constraints import CheckConstraints

class Person(models.Model):
  first_name = models.CharField(maxlength=50)
  last_name = models.CharField(maxlength=50)
  check_name = CheckConstraints(last_name__neq = first_name)
  gender = models.CharField()
  check_gender = CheckConstraints(gender__upper__in = ['MALE','FEMALE'])

This prevents both first_name and last_name being the same and the upper case value of gender must either be a MALE or a FEMALE.

The Value based constraints being

 * IN to check whether the input is in a given list
 * LIKE to check if the operand resembles a value (regexps are possible)

Example:

from django.contrib.constraints import CheckConstraints

class Manufacturer(models.Model):
   name = models.CharField(maxlength=50)
   check = CheckConstraints(name__like='Merced%')

 * NULL to check if the given value is a Null or not (already implemented)
 * UNIQUE to check for uniqueness of column in the table (already implemented)

Example 3:

from django.contrib.constraints import CheckConstraints
from datetime import date

class Project(models.Model):
  proj_name = models.CharField(maxlength=50)
  check_name = CheckConstraints(proj_name__like='World_Online%')
  start_date = models.DateField()
  check_start_date= CheckConstraints(start_date__gte = date(2007,01,01))
  end_date = models.DateField()
  check_date = CheckConstraints(start_date__lte = end_date)

The above model checks if project name contains World_Online at the beginning of the proj_name, the project start date is after January 1st 2007 and project end date is after the start date. Simple database based validations done with three small lines in Python (also these lines are similar to the field set lookups, so not much of learning required).

When are these check constraints invoked?

These check constraints are called whenever a model object is created or edited.

Benefits of Check Constraints:

 * Allows the programmer to write constraints in Python (without having to know SQL)
(Sticking to Django's philosophy, purists will not be disappointed.)
 * Check constraints are used to ensure the validity of data in a database and to provide data integrity. If they are used at the database level, applications that use the database will not be able to add invalid data or modify valid data so the data becomes invalid, even if the application itself accepts invalid data.

 * Check constraints provide better data integrity. As check constraints are always executed whenever the data in the column upon which they are defined is to be modified.

 * Check constraints promote consistency. Because they are implemented once, in the table DDL, each constraint is always enforced. Constraints written in application logic, on the other hand, must be executed by each program that modifies the data to which the constraint applies. This can cause code duplication and inconsistent maintenance resulting in inaccurate business rule support.

I propose work on enhancing Drupal's Project module to add a system that computes a number of quality metrics to assist in rating projects. These metrics will help users determine which of the many contributed modules and themes are being actively developed and maintained.

This proposal is about implementing an Extensible Messaging and Presence Protocol (XMPP aka Jabber) interface for Drupal, which would allow the system to interact with its users via instant messaging. The primary goal of the project will be to implement XMPP extension XEP-0060 (Publish-Subscribe), along with its dependencies, using only PHP and no external jabber software. This will give Drupal users the ability to choose IM as an alternative, to e-mail, medium through which various system messages are delivered.

Initial development will concentrate on one-way communications, with messages being sent from Drupal to its users. Eventually, it is my hope to extend the framework into a fully-functional XMPP server, allowing for two-way communications and a whole new way of interacting with a content management system.

Synopsis

The Project module, together with its companion project_release.module, makes extensive use of the CVS module in order to accomplish revision control system (RCS) integration. In order to get drupal.org's new release system done in time, the Project module has been made even more dependent on CVS specifics, making it hard to impossible to use Project's functionality together with other revision control systems.

During the Summer of Code, I want to decouple the Project module from the CVS module and move CVS specifics into an RCS independent API. At the end, cvs.module should only be one of several possible backends for the RCS API, so that supporting other revision control systems like Subversion, Mercurial or Git can be achieved with reasonable effort. As an additional advantage, other projects like Case Tracker can also make use of the RCS API in order to integrate revision control functionality while sharing as much code as possible.

What is specifically not planned for this project (though possible in case that the existing deliverables take less time than expected) is Subversion support itself. I decided to leave this task out because all the knowledgeable developers that I contacted estimate more time needed for the groundwork than what it would originally look like. So I'll concentrate on just getting the Project module to be RCS independent - which, according to dww, is the majority of the work - and leave actual Subversion support to a future project.


Motivation

Getting rid of the hard dependency on CVS will benefit a lot of people who want to use the Project module together with their internally used revision control systems. drupal.org itself makes heavy use of the Project module, and if drupal.org ever wants to switch to a more modern revision control system (like Subversion which is frequently in the talks) then RCS abstraction is a basic requirement for such a switch. However, as mentioned above, writing the actual Subversion support itself is not in scope of this project.

Design a new core theme


Synopsis

Although Drupal has a very nice core theme (Garland) since version 5 it would be great to offer an additional theme that's more suitable for customization. Think CSS Zen Garden (http://www.csszengarden.com/), where most of the design changes can be done by only editing the CSS.
Of course the design should also be pleasing to the eye, yet it should offer something different than the current blog oriented Web 2.0 theme. Making a more authentic look (see http://www.simplebits.com/) will make Drupal look more professional and classy.


Motivation

This project was proposed on the Drupal website (http://drupal.org/node/124067).
I've installed Drupal several times already. One of the most time consuming things during deployment is tweaking the default theme or using it as a base for a new theme. That's why I think it is interesting to develop an additional core theme that doesn't only use a different style but also makes customization or using it as a base for a new theme easier.


Project

I will split up the project in the following parts:
- Design a mock-up in Photoshop
- Make an XHTML/CSS mock-up from the Photoshop version supported across most modern browsers
- Implement the layout in a PHPTemplate theme
- If possible and needed enhance certain areas with JQuery or the Drupal Color module

Because many people have had their share of Web 2.0 or "kiddy" layouts I thought it would be interesting to use a more authentic look, similar to what Dan Cederholm did with his personal website SimpleBits (http://www.simplebits.com/) or Cork'd (http://corkd.com/). This style tends to make a website look more serious or professional and it will make a visitor feel more comfortable.
Before making the actual design using a graphical tool I will outline the layout of the page and choose a color palette that is both modern and close to Drupal's current style. When that's finished I will start designing the mock-up for the main content types Drupal uses (main page, node, admin dashboard, forum, list of articles, generic blocks, etc.). Attention will be given to Drupal specific features and how to make them more usable (eg. primary/secondary navigation, search box, left/right column, etc.).

Once the design mock-up is finished an XHTML/CSS version will be made. It's crucial that the XHTML is semantically correct and offers enough hooks for customizing the theme using only a CSS file (see http://www.csszengarden.com/). This should be applied to all the default content types and blocks Drupal offers.
Next to that additional stylesheets will be included for mobile view or printing. A nice feature to add might be different stylesheets for a fluid, fixed or hybrid layout.
The CSS files will be very well structured and class and id names will be chosen appropriately in order to ease quick customization of the theme.

When the XHTML/CSS is done a PHPTemplate should be made, overriding most Drupal template hooks in order to make the theme feel consistent across all Drupal features and default modules.

If time permits the new theme will use the same approach as Garland regarding colors. There will be a feature enabling Drupal webmasters to easily edit the theme's colors without knowing any XHTML or CSS.

A new module which provides a powerful interface for Drupal’s core taxonomy module for managing terms.

Make Case Tracker Module more like a project manager.

The goal of this project is to build an aesthetically pleasing core theme for Drupal.

Despite the numerous elegant sites that have been created and beautiful themes developed, Drupal is perceived by many to be lagging behind other CMSs when it comes to 'look and feel'. One of the main strengths of Drupal could itself be the reason for this problem: flexibility. A generic theme will have to incorporate each aspect of Drupal whereas a typical site would only need 20% - 30% percent of these features. Also, designing without knowing the target audience, content and marketing goals is a difficult task, and the results may not be applicable to many situations.

A good core theme would have to address the needs of applicability, customizability and flexibility to ensure easy adoption by the users. It will have to be usable, standards compliant, and accessible. Garland is a good example of how these goals could be achieved, and how effort put in to design could really pay off. It would be wonderful for both Drupal and Drupal users if there were more options to choose from, without compromising on the features. That's where a new core theme would be very useful.

The project to create a new theme would be done in four phases:

1. Initial Research: I will need to educate myself better on the Drupal project itself, the processes, the designers and their views, as well as the requirements of a core theme.
2. Visual Design: Based on my initial understanding of the requirements, I will create the first mockup of the design. This would be improved through an iterative process where I would work closely with the mentor and the relevant experts and community members. As a relative newcomer to Drupal, I would need the guidance and assistance of Drupal designers to ensure the design meets the needs of the community.
3. HTML Template: The finalized mockup would be converted to an HTML template. I would use valid, semantically correct XHTML markup, and valid CSS. Drupal has good accessibility features out-of-the-box[1], so I will make sure we improve on them.
4. PHPTemplate theme: In the final phase of the project, I will work on converting the HTML template in to a fully-fledged Drupal theme. As in earlier phases, I would rely on the assistance of my mentor and other Drupal experts to make sure the project has a successful result.

SVG is a modern vectorgraphic standard to handle graphics on the web. Drupal so far lacks both a general drawing API, and specific drawing APIs, like SVG, or GD. My goal is to implement

a) a general drawing module, a geometry library, upon which I am intending to build an
b) SVG drawing API.

Clearly these two are a bit separated fields, the SVG drawing will require a well-thought basic geometry library, the drawing module.

===Drawing API===

A general, well-thought drawing API can make it easier for later toolkits (GD) to build graphic applications for Drupal. This API will include descriptions and definitions of basic shapes, primitives (lines, shapes, text) as well as a "canvas management", the ability to handle multiple grouped objects.


===SVG toolkit===

I am looking forward to implement an SVG toolkit in Drupal, because I believe it has multiple features that this great CMS can use well. It is open, XML based, basically platform independent (though implementations might lack, but support is available in form of plugins for browsers where it is not built in), and vectorgraphic. Exploiting its capability for asynchronous transfer one is only limited by his/her fantasy what kind of graphically rich applications can be built upon it. Ranging from statistics display to geographic applications the limit is only the human mind.

I personally also see a huge opportunity in helping the scientific community with this implementation - where the demand is often to search in big databases an interface displaying only the canged information can be extremely helpful. Providing new ways to display information and integrating it with Drupal CMS will make it easier for students to interact, to get involved in scientific projects, and also for research groups to interact and work together better.

The SVG API will follow the 1.1 specifications, will have the functions for turning SVG on/off, handle the drawing and distorting of shapes.

Project description

There are at least five different modules in Drupal that deal with
RSS/Atom aggregation and node creation in Drupal. All of these
modules are slightly different with some sharing similar or the same
parsers and others using the same third party parser. All of these
modules may have something to offer, as well as may need the same
missing pieces to become an ideal aggregator API.

Work with the leech module itself proved the need for adaptive
leeching - knowing how often to check a feed for new items based on
the probability that the feed would have new items. This is needed
because if you have 1,000 feeds and they are all checked on the hour
every hour during cron, this causes problems. There are other modules
that work to offer ways around this shortcoming, but this is just one
example of where further improvement can be made.

The project will include a review of features across this module
pool, as well as consider ideas on how to improve some of the common
problems these modules face. The end result will be the following:

1) A review of the existing aggregator solutions and a matrix of
their features.

2) A consolidated aggregator module/API that takes the best features
and aspects from the pool. This will answer some of the common
challenges facing all aggregators, such as adaptive leeching, parser
selection and capability, node creation, and feed item element
handling (how to store which items within the Drupal architecture).

3) An install profile to assist with the installation of the
aggregator module, as well as complimentary modules for running a
news tracking website.

An additional positive result, though not the focal point of this
project, will be more insight into caching needs with websites that
aggregate and store a lot of information.

This project aims to provide new techniques for enhancing scalability and identifying bottlenecks in the Drupal project. In addition, I also hope to provide any resources necessary (including documentation, tools, and modules) to load balance Drupal across multiple servers and implement fail over servers.

The three core aspects of this project are as follows:

1. Develop a system to automatically load test Drupal sites.
 * Automatic generation of test data. There are a number of areas that may cause Drupal to slow down. Most modules will work smoothly until they have data they need to use. This tool will likely use and build on the generate scripts that come with the devel module to populate a site with test data. It will also incrementally add more data to the site, running benchmarks at each increment. This will help to identify modules that may work smoothly with a small amount of data, but degrade exponentially as data increases.

 * Build stress tests to run on the system. The stress tests will be targeted towards both specific modules and more general tests on an entire Drupal site. The SimpleTest module framework may be useful for building these tests.

 * Automatic testing of different combinations of modules. To determine which modules may be slowing down a site it can be useful to enable different combinations of modules to test against. This tool will automatically:
  1. enable modules one at a time
  2. enable each module by itself (dependencies will also be enabled)
  3. test groups of modules that are related. This will be based off of dependencies and user specified rules.
 After each iteration or change to the site, the site will be benchmarked and a report will be generated.

2. Identify bottlenecks in Drupal core and submit patches to correct the issues. During testing of the above tools bottlenecks may be identified in Drupal core, core modules, and popular contrib modules. Patches will be written to help eliminate those issues. For more serious issues that can't be resolved with simple patches, recommendations will be made to resolve the issues.

3. Provide resources to allow administrators to setup Drupal to scale horizontally across multiple servers and use fail over servers. This will come in the form of documentation, tools, and patches to help administrators configure their sites.

The Drupal BitTorrent Tracker project looks to provide Drupal users the power of the BitTorrent protocol when moving large files from their website to their visitors. The main outcome of this project will be a BitTorrent “invisible tracker” that integrates with Drupal through a module. The module will allow for the addition and removal of torrents, IP address management (banning IP addresses or ranges) and statistical presentation concerning information about the tracker (current seeders, leechers, swarm speed, active torrents, etc.). Special emphasis will be placed on minimal database interaction and ease of use. A user of the website should be able to download a .torrent file and use their client of choice without the worry of tracker failure. The same ease of use should be available to the administrator who should be able to add and remove torrents as well as view statistics concerning the tracker in real-time. With this module, Drupal users will be able to offer secure, fast, and large downloads to their users.

The Drupal automated staging toolkit is a proposed set of code libraries, file schemas and parsers, and code generators, for automatically creating a Drupal site with specific module code versions, sample users and data, and a specific LAMP stack configuration for hosting the Drupal site. The toolkit also has the ability to stage this generated site on an existing physical server location, and also as a self-contained virtual machine consisting of a minimal Linux environment, required LAMP software, and the Drupal site.

The automated staging toolkit is designed to be part of an automated unit- and regression testing environment, by providing testers with a simple, fast way to automatically generate a complete Drupal site running specific code versions, and using specific LAMP server configurations. It is also intended for use as part of a performance and scalability testing environment by providing the ability to rapidly build and then benchmark the effects of different application, web and database server configurations on Drupal site performance and scalability.

This toolkit will be used in the following way:
1. The tester creates or reuses an XML(or other structured) file using a schema describing the Drupal site code-tree, including modules installed/enabled/disabled, and the versions of each module to be used.
2. The tester creates or reuses an XML file using a schema describing the LAMP stack web server, PHP/application server, and database server configuration; e.g Apache vs. Lighttpd, mod_php vs.FastCGI, choice of op-code cache, MySQL vs. PostgreSQL, and so on.
3. The tester creates or reuses an XML file using a schema describing the sample users and content data the site will contain.
4. The parsers take each file and generate scripts in a lightweight language (Python or Ruby or PHP-CLI.) These scripts, when executed, use functions in the code libraries to download Drupal modules, generate database scripts and datasets, and write server configuration files.
5. Given a physical server target location, the Drupal modules, database scripts and server configuration files are deployed to the designated server location, to produce a new, ready-to-test Drupal site.

Time and resource permitting, a builder in the toolkit will also use the generated Drupal site and servers' configuration as input to build a self-contained virtual machine image in Xen, VMWare, or potentially the Amazon EC AMI format. This virtual image can also be be used in testing environments, including advanced performance testing scenarios such as evaluating clustering, distributed database topologies, and alternative storage and computing models like Amazon S3 and Elastic Cloud. The ability to rapidly generate self-contained Drupal virtual machine images will also be extremely valuable to Drupal consultants and solution providers for marketing, prototyping and demonstrating Drupal solutions to potential clients, and large organizations and ASPs like CivicSpace looking to take advantage of the massive benefits of virtualization technology from VMware, Xensource, Amazon, and the like.

The SMS Framework project will improve and expand the SMS technology integrated into Drupal powered applications and websites and make it easier to incorporate SMS elements into Drupal websites. To carry this project out, I will research existing SMS solutions for Drupal, identify shortcomings, and build a driver based API that can be ex-tended to work with common SMS service providers and integrated into Drupal core and contributed modules.
An improved SMS framework for Drupal will enable individuals and organizations to seamlessly and easily combine elements of mobile and online campaigns on their Dru-pal websites. This will be very helpful to nonprofit, advocacy, and political organizations.

Synopsis:
  Although drupal is selfsufficient for any corportate site
  development, having to search and find the internal references
  while preparing documents is a drawback in using it for a site
  full of articles and documents like Wikipedia. My project
  solves that by looking for keyterms in the text, and listing
  them categorized by the relevant key terms. This enables the
  user to maintain the line of thought undistracted.

Benefits to Community:
  I believe this will make drupal more user-friendly,
  especially document-writer-friendly and reduces the time spent
  in searching for internal references and let the user worry
  about the content than the connections.

  The project can be tested for its success based on the
  fulfillment of the requirements described above,
  compatibility with most of the browsers and the
  adoption of the service by the drupal community, which
  I never doubt.

Statistics interface will provide a complete overview about informations published on the DSpace platform.

It will be possible to know all the stats related to the user visit, for example:

- Number of hits per day/month
- Number of pages per day/month
- Popular pages
- Number of hits per page
- Number of hits per Community
- Number of hits per Collection
- Number of hits per Item

Upon these informations it is possible to create different views.

To provide these informations, there is a simple API, that can be used everywhere in the DSpace platform. The basic object for this API is LogEvent, a class that maps the standard informations for an event system.

Informations about events are saved into the DB and then there different way to show these statistics, in a simple and configurable way.

It will be saved also informations about user of the website, using MaxMind - GeoIP Java API (http://www.maxmind.com/app/java).

All the informations collected by this application will available under different formats.

At the URL http://wiki.dspace.org/index.php/Google_Summer_of_Code_Statistics is available detailed description of the project

I will create a branch to the DSpace codebase representing the effort to support versioning among Items. Versioning here is a linear series of revisions and not various representations of the same content. This is a very commonly requested feature among users of DSpace and the whole effort is in line with the recommendations of the DSpace Architecture Review Group.

With the price of computer monitors dropping, more and more people choose to work in a multi-monitor environment. Working in this way can be very helpful when there are large quantities of information you need to process at one time. One of the best examples: software development. Working on projects in Eclipse on a dual or triple screen display is possible – but not that efficient as with other IDEs out there. Though useful, detached views become difficult to work with when you have many of them. Detaching multiple views (to move to to another screen) is an easy task – but to arrange them, you need to do it manually. It should be possible to have the same functionality that is exposed in the workbench: sashes!

Another common task for an application today is a fullscreen mode. As seen in other development environments, this can help to concentrate on the source code itself instead of being distracted by all the views, icons and other things around the editor area. Also, the size of the editor component can be improved by disabling the toolbar, statusbar and window border in fullscreen mode. This is not only useful with multi monitor setups but also for single monitor environments.

Understanding dependencies between plug-ins in Eclipse is a complex task. The current plug-in dependency analysis tools available in Eclipse are restricted to simple tree views with drill-down support. Throughout this summer, I propose to add visualization support to the Eclipse Plug-in Development Environment (PDE) in order to help provide cognitive support to developers as they analyze their plug-in dependencies. I intend to complete the plug-in view that I started in the fall of 2006 by adding new dependency filters, improved navigation support, and the ability to highlight plug-in dependency analysis paths.

This project proposal serves two purposes. Firstly, in brings plug-in visualization to the PDE, and secondly, it provides exemplary tools for the Zest framework. Zest is an Information Visualization Toolkit for Eclipse. While Zest was initially developed to provide visualization support for Mylar, its usefulness is now being realized in several Eclipse projects. By creating exemplary tools based on Zest, this will improve the visibility of Zest and ultimately bring a lightweight visualization framework to the Eclipse platform.

Deliverables:
Complete the PDE View and add 3 plug-in filters:
 o Filter by JRE Version
 o Filter by Enabled / Disabled
 o Filter by Regular Expression (on bundle name)

Add dependency path analysis (show why a plug-in is required by highlighting dependency paths).

Add improved navigation support
 o Forward and back button support
 o Add search support for the list of show plug-ins

Currently, views that depend on GEF cannot be shipped with the Eclipse platform. I intended to complete a full refactoring of the plug-in view to remove all GEF related dependencies, relying solely on Draw2D. Once this is completed, I will investigate the possibility of making the plug-in available in the Eclipse Platform (either as part of the SDK or as a separate download) along with the Draw2D jars.

This project aims to add the ability to externally invoke commands in Eclipse via a web browser.

For example, this could enable a site to provide a link which would cause Eclipse to fetch and open a source code file in a single click. A sample link might look similar to the following:

<a href="http://localhost:56789?command=open_file&filepath=http://someWhereOnTheWeb/foo.java">open this file in Eclipse!</a>

Eclipse will listen for these requests and, when received, invoke the command in one of the currently running Eclipse instances.

I plan to extend Chris J Daly’s Gymnast (described in Language Toolkits Technology Exchange, EclipseCON 2005) so that it supports:

a.1) generating EMF-compliant classes for Concrete Syntax Tree nodes. With that, using OCL (Object Constraint Language) becomes possible to check the well-formedness of CSTs before transforming them to ASTs. The author of such transformation may thus employ QVT-style technology, e.g. ATLAS ATL.

a.2) generating an LPG grammar in addition to those already supported (ANTLR and JavaCC).

a.3) generate a visitor to unparse a CST into a pretty-printed representation, re-using hints specified in the existing Gymnast grammar format. For example,

sequence ifConstruct :
    “if” expr
        “then” expr
        “else” expr
    “endif”

would result in unparsing following a similar layout.


a.4) generate a text editor with usability features. The design patterns to generate have been harvested while implementing the Emfatic extension for EMF Generics. These usability features include:

Outline view, Mark occurrences, folding,
Hovers displaying declaration for a given usage,
Live problem and warning markers, Navigable hyperlinks,
“File New” wizard, AutoEdits such as SmartBrace (i.e. automatically completing with a closing terminal),
User-provided templates,
Syntax-aware Content Assist.
Refactoring will be explored (at the very least, by updating usages-for-declarations)

A common theme consists in making the most out of the input specification. For example, the type-checking rules for expressions in a DSL are usually not specified declaratively. OCL (Object Constraint Language) can uniformly be used to specify static semantics and type-checking rules, as shown in:
http://www.sts.tu-harburg.de/~mi.garcia/pubs/2007/mdsdHeute/garcia-emfgen-2.pdf

Tips on processing OCL are reported in my Eclipse Technical article (under review), at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167543

Once the extensions a.1) to a.4) have been implemented, an IDE for Gymnast will be bootstrapped with the Gymnast generator. Additionally, a case study will be undertaken to validate the approach, i.e. an IDE will be generated for one of:

b.1) an ExecutableUML-style language but EMF-based

b.2) EJB3QL, building upon the metamodel described in
http://www.sts.tu-harburg.de/~mi.garcia/pubs/atem06/ EJB3QLpaper.pdf

b.3) a human-readable notation for UML2

Preparing developer documentation (and community articles) is an integral part of the planned tasks.

Framework to develop simple Eclipse plugin using PHP. Create a framework that could support developing simple Eclipse plugin using a PHP To Java bridge (Like Caucho's Quercus and other JSR 223 engines). Develop and document a sample plugin in PHP, so that PHP developers could create simple plugins.

The idea is taken from the Eclipse SOC 2007 Ideas page http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007_Ideas

Project title: Improve Mylar's new users experiences

Project description:

The project's goal is to write a plug-in which presents for the new users Mylar from the basics to the every days use. And for the other users it will help too with the built-in help.

The plug-in contains:
* a welcome page which contains:
 * new & noteworthy information
 * tutorials
 * in the overview menupoint a link to the Mylar description text
 
* cheat sheets which show the use of Mylar through examples:
 * each presentation of the 3 views (task list, repositories, activity) (properties and basic using)
 * focus working
 * connecting to the database and adding new repository (to all connectors)
 * adding new query
 * modifying query
 * opening, activating, synchronizing task
 * making and using local tasks
 * categorizing the tasks

* filling the built-in help from the wiki page informations:
 * User Guide
 * FAQ
 * Tips & Tricks
 * Information for the developers: references, components description

After we written a java application by Eclipse, we should type a command like "java myapp.class" or "javaw -jar myapp.jar" to run our application. Though we can write a .bat file on Windows or write a shell script on Linux to do the job, it feels not very convenience.

The aim of this project is to develop a plugin for Eclipse to wrap compiled Java applications and give out a excutable file. It is supposed to support both Windows and Unix-like Systems.

There are some similar tools:
1.exe4j(http://www.ej-technologies.com/products/exe4j/overview.html). Exe4j can integrate Java applications into the Windows operating environment. It is a business software and it need to pay to get a license.
2.JSmooth(http://jsmooth.sourceforge.net/index.php). JSmooth is also a Java Executable Wrapper. It also creates native launchers on only Windows operating system. JSmooth is free software under GPL.

Currently, there are several large efforts to develop a comprehensive IT healthcare infrastructure that would allow interoperability and sharing of information within and across healthcare organizations and regions. The Eclipse Open Healthcare Framework (OHF) is an open-source approach to this problem that relies on Eclipse's tooling environment.

I propose to build a token-based XML generator that allows the mass generation of messages for test purposes, a project within the scope of the OHF. These test messages have to be manually generated right now, and providing this feature would help ensure that messages and their models are effectively tested before being officially released to healthcare application vendors. This testing is particularly essential in healthcare, where errors can cost lives.

This project would extend the Message Instance Editor, an OHF tool produced by the Health Level 7 (HL7) V3 Eclipse Tooling group (H3ET). The Message Instance Editor is used by international standards bodies such as HL7 and governments (the UK National Health Service) to generate, edit, and validate healthcare messages that conform to the HL7 version 3 specification. Users of the Message Instance Editor have requested the ability to generate batches of example messages based on the schema-like constraints imposed by the HL7 Model Interchange Format (MIF). Therefore, my project would:

   1. Create an XML representation of an example message template.
   2. Create a new wizard that would allow a user to generate example messages based on the template and HL7 message models (from a MIF file).
   3. Allow replaceable tokens to be defined within example message templates that are replaced by example data.
   4. Allow configuration and declaration of these tokens.
   5. Allow the user to configure the behavior of the batch message generation.

I will implement an EFS implementation for WebDAV to allow Eclipse platform users to use remote WebDAV repositories as mount-points for projects and files. This will benefit any user of Eclipse who wants the flexibility to store their files in this way. Being able to treat remote repositories as if they were local is beneficial to many development groups including web designers, server-application developers, and anyone creating Eclipse plug in update sites.

This is about Mylar synchronous context sharing among team members by means of Mylar and ECF integration. The goal of such context sharing is to provide more seamless knowledge sharing process, allow sharing context synchronous even if the used connector does not support context sharing or no connectors used at all.

The synchronous context sharing means that it is possible to share context on fly with a friend who is currently online and you are discussing some issue. It will be possible to create a task for new context or assign this context to an existing one.

Technically, the solution will use ECF to handle all communication details. I will try to employ current Mylar’s context sharing functionality. This solution will provide SWT-based user-interface for context sharing and I will also include the rainy scenarios handling, such as “no connection with friend” or “file resources are out of sync”.

Background:
Searching is one of the most commonly used features of Eclipse. However, this feature has mediocre performance compared to text processors like VIM or Emacs. In some cases, like searching for a string in compressed Javascript files (the whole file is one big line), lack of a good search tool becomes prominent.

Purpose:
Aside from quirks in text search that need to be fixed, like the case of files that are not well-structured (e.g. compressed Javascript files in one line), other improvements can be done by integrating the search process with Google Code Search and other resources.

Developing an Eclipse search plug-in that improves performance and relevance is the main concern. By proper integration with online code repositories, this tool will also speed up learning and code observations within Eclipse itself.

Project Description:

Inspecting and making use of Lucene, OpenGrok and other search tools and algorithms, I'm planning to create a plug-in that can speed up text-based search in Eclipse.

When the search plug-in reachs maturity, I want to enable support for Google Code search and support for other possible code repositories. For this feature, I'm going to create a mechanism to add more repositories as search locations (example: adding new websites to Firefox search bar). These repository info files will be easy to compose and the plugin would enable composing such files. At last, I intend to support CVS code search.

Project Schedule:

Today to May 1 - I'm going to focus on research about existing defects, possible algorithms to apply and learning about Lucene, OpenGrok and other new solutions to the problem. I'll try to code crude prototypes of these possible solutions.

May 2 to May 22 - After discussing possible solutions with my mentor, I'll identify the solution approach and organize myself to code that solution

May 23 to July 16 - I at least expect to see a basic search tool that works fast and provides good results when it works (in the use cases I have finished implementing). After the midway evaluation of my mentor at July 16, I'll know which parts to improve from this point.

July 17 to August 1 - In the light of my mentor's advice, I'll focus on fixing important weaknesses of the tool. Upon fixing these weaknesses, I'll try to prepare further documentation for other developers.

August 2 to August 20 - I will be implementing prototypes of extra features such as integration with Google Code search and CVS code search support. As I plan to always keep myself focused on the correctness of core features of the plug-in, I will test these core text search features further.

August 21 to August 31 - Upon receiving final feedback from my mentor, I'll polish the online/repository search capabilities of the plug-in in the first week of this period. In the remaning time, I'm planning to test,fix,document and discuss the beta version of the plug-in with the community.

Groovy is ideal choice for a seasoned Java developer for its speed of prototyping and flexibility for development. As in case of Eclipse support for Groovy plug-in development, the biggest benefit of on-the-fly plug-in code writing/changing, as one don't have to start a separate Eclipse instance while testing my plug-in under development. This would rapidly improve the speed of lightweight plug-in development.

This project aims to add ability to write plugins in JVM-based scripting language, like Groovy and JRuby. But it could be a starting point for any other JVM scripting language, like BeanShell or Jython.

The main results to be reached:
- An Eclipse extension/plug-in to (re)load (Groovy) scripts on the fly.
- Command line console support. (This could look like in case Apache Derby ij plug-in)

Eclipse is an extensible framework to build modular applications, which relies on OSGi component architecture. Originally developed to provide an IDE extensible in terms of functionalities and supported languages with plugins, Eclipse can now be used as a Rich Client Platform (RCP). The success of the Java Development Toolkit (JDT) plugin has leaded the development of numerous plugins. For instance the C/C++ Development Toolkit (CDT) plugin allows developers to use it as IDE for project in C or C++ language. The use of Eclipse as a generic IDE is possible due to the notion of perspective (a perspective corresponds to a certain disposition of the graphical elements) which adapts the user interface to the kind of project.

    Java Native Interface (JNI) is a programming interface to call native methods or to embed java virtual machine in native applications. JNI is often used to interact with existing native application, to add platform-specific functions, or to improve time-performance (by supposing native methods faster than java code).

    Currently, when users work on a java project using JNI and native code, they have to switch between perspective, which is not practical. Another point to improve is the debugging of this kind of project, by allowing developers to follow native method calls into native code and go back.

* Goals of the project
    - create new or "mixed" perspectives to manage project using C/C++ and Java
    - add the possibility to follow native methods calls into native code

* Roadmap
    - Announce the project and check the existing work (see http://cdtdoug.blogspot.com/2006/09/jdtcdt-cant-we-just-get-along.html). Get feedback from CDT and JDT community and discuss with them about the project [until May 28]
    - Implement the work on perspectives first and then the native method calls follow-up [until beginning or mid of August]
    - Integration and tests with the help of the Eclipse community

Tor is an important tool for maintaining privacy on the Internet. Too keep the Tor network healthy, many servers are required. With many homes having ready broadband access, even relatively non-technical people have the ability to contribute. This bug effectively prevents these people from participating, cutting off a large source of servers for the Tor network.

I propose to fix this bug by adapting libevent to the Winsock API (instead of using select()) in such a way as to use overlapped IO and fix the buffering problem. As part of this process I will develop a stress tester (probably in conjunction with TorFlow) for use not only with this bug, but for regression testing and performance-based stress testing.

These changes would be written in the languages required to interface with existing code - C for Tor and libevent, python for the stress testing client (with TorFlow), and documentation, coding style and testing standards would be maintained.

For more information on this bug, see: http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems

Tor provides a mechanism for responder anonymity via hidden services. As a part of these, Tor provides storage on its central directory servers to allow publishing and retrieving rendezvous service descriptors. This proposal suggests to replace the centralized approach by a distributed storage of descriptors to the larger set of onion routers. Benefits include (1) better load balancing which is vital for the further growing of the network, (2) a more scalable way to publish descriptors, and (3) extensibility of hidden services to features like human-readable names or client authentication. As possible drawback can be seen that new threats arise due to decentralization that need to be discussed and handled.

In this project a structure is applied to the network of onion routers, based on concepts known from distributed hash tables and consistent hashing systems. Every participating router is made responsible for a limited set of descriptors. It is not necessary to maintain an own routing table, but possible to rely on the router list managed by the Tor directory. Some amount of replication needs to be added to overcome node failures and untrustworthy routers. This prevents the worst security threats, as descriptors are signed and have a limited time-to-live. Thus, they cannot be forged or replayed. Preliminary measurements show that routers exhibit a very low churn rate which makes them a perfect field for consistent hashing. The purpose of this project is to extend the current Tor sources to a running prototype that contains a distributed storage of rendezvous service descriptor.

The gPXE, while designed to be portable, currently only
runs on the ia32 and the ia64 cpus. Yet it's still
desirable to get it running on some of the other platforms,
like the ARM.

I'm willing to port the gPXE to the ixp42x cpu family, adding
support for the Intel IXP42X Development Board and maybe a
number other popular devices based on this cpu.

GCC currently only supports generating 32-bit code for the i386 platform. Etherboot requires 16-bit real-mode code in some places, some of which is written in C. Currently, this is accomplished with a hack (.code16gcc), but this produces larger code than necessary. My proposed project is to add a 16-bit i386 backend to GCC to obviate the need for this hack and reduce code size.

gPXE is a rewrite of Etherboot project with several major improvements. One of the goals, is to update Etherboot network interface card drivers to work with gPXE. This will require making API changes to allow existing drivers to work with the new gPXE API.

This proposal is based on the ideas for reducing code size which have been posted on the Etherboot Project ideas page.

The ideas presented there are

a) using gcc function attributes where applicable to allow further optimizations, possibly looking into register parameters as well

b) looking for symbols not referenced outside their object, making them candidates for either static declaration or elimination

My first step would be setting up a code xref tool like LXR or OpenGrok, to get a better feel for the control flows and general structure, as well as the most used functions.

Then the above ideas would be tested for their potential of code reduction. For the functions, this would probably mean going through the list one by one, looking if they are candidates for pure, const, regparm, maybe even noinline, nonnull or the like. As already mentioned on the ideas page, I expect a lot of experimentation in this phase to find out what helps and what doesn't.

Time and resources permitting, as a third step general code profiling could help identifying functions with potential for further reduction in size.

If those ideas turn out to be viable, the result should be a patch set to include the attributes and static declarations, which hopefully delivers a notable reduction of code size.

The goal of the project is to implement a driver that enables developers to access an eXist Xquery engine from a Java application. The implementation will follow version 1.0 of the XQuery Api for Java which attempts to provide a common way for Java developers to interact with XQuery engines. Over the years, XMl has become the predominant data interchange format and the eXist library provides developers with an easy and powerful way to manage, store and query their XML based databases. I believe that an XQJ driver for the eXist library will prove to be very valuable for the open source Java community as well as the eXist community.

An eXist Database can be deployed essentially in two ways : either as en embedded library that runs in the JVM of the client application or as a standalone server possibly located on a remote host. A different XQJ driver is therefore needed for each one of those use cases.

Deliverables : 2 XQJ driver packages for eXist engines
    ->A local connection driver to be used when accessing an embedded eXist database
    ->A remote connection driver to be used for remote standalone eXist databases

The goal of this project is to develop a vector version of FANN which can take advantage of modern CPUs like those implementing SSE or similar technologies.
Another goal of the project will be to add utility apps/functions/scripts in order to make using FANN easier. A fann_trainer script or application will be in good shape at the end of the project and will be capable of training different kind of network with appropriate algorithms.
If projects for a FANN GUI are accepted I'll collaborate with the other student in order to make the utilities well integrated.

Competitive artificial neural networks have increasingly become popular for visualization and clustering of the large amounts of data existing in many scientific fields. They are also used for pattern recognition, image analysis, and many other applications. This project will add Self-Organizing Maps and a similar dynamic algorithm called Growing Neural Gas into the FANN library. The implementation will be coded so as to support extensions such as adding multiple learning rules
and neighborhood functions, and include features such as calculation of quantization error and other metrics.

My background on the subject:
At my university, I've started to collaborate (as co-developer) to an open-source project: HuMoR. It is an intelligent video surveillance application, with a (working-in-progress) GUI to manage the HuMoR core.
It is written using the QT libraries and, thanks to HuMoR, I have acquired a good knowledge of QT and its philosophy.
Right now I have good skills in C++, QT coding and UI design.

Using QT became possible to have also a real cross-platform native GUI, especially with QT4 (windows, linux, macOs).
 
Goal:
My objective is to create a user-friendly cross-platform native GUI using Qt4 libraries.

I will implement both representation of a neural network and the execution of it on the GPU as well as a training algorithm. This will hopefully speed up the FANN-library that already is a fast lib. To accomplish this i will use GLSL to maintain the platform independence.

The most important process of the Fedora Localization Project is the translation of Fedora resources (applications, documentation, websites, etc.) in various languages. Contributors identify a resource that needs translation, receive the respective `PO`-file, translate it, and commit the changes to our Source Code Management (SCM) system.

The system currently used allows translations of resources hosted on the same system but not on other systems, such as the main SCM of Fedora or remote SCMs.

Our goal is to build a platform that will facilitate localization processes of the Fedora L10N Project and other l10n communities. I will pursue this by deploying a Web User Interface for translation statistics which will also give translators seamless access to upstream-hosted translation files. This automation will benefit both the Fedora L10N Project in terms of usability and the upstream projects in terms of translation completeness.

The full application can be found at: http://fedoraproject.org/wiki/SummerOfCode/2007/DimitrisGlezos

I would like to develop an enhancement to Pirut that will enable users, who do not have the necessary bandwidth to download packages from the Internet, to install and update from packages downloaded on a different machine having better connectivity. This is inspired from one of last year's accepted proposals mentored by Ubuntu [1].

[1] https://wiki.ubuntu.com/OfflineUpdateSpec

Real Video 4 is one of Real Video family codecs. It is believed to be based on some standard (H264?) or standard draft.

Matroska is a container format that's capable of holding almost any combination of audio and video codecs. It has recently been gaining popularity. FFmpeg is perhaps the world's largest open-source multimedia solution, found at the heart of many media players. This project aims to write a simple Matroska muxer in C for FFmpeg's libavformat. This will better enable the creation of Matroska files from the many applications that utilize FFmpeg.

FFmpeg's libavcodec library has become the de facto standard library for video decoding and encoding in free software projects. Unfortunately, no similar standard library has surfaced for filtering and otherwise working with video once it has been decoded. Various projects (MPlayer [1], Xine [2], GStreamer [3], VirtualDub [4], etc) have implemented their own systems to various degrees of success. What is needed is a high quality video filter API - efficient, flexible enough to meet all the requirements which have led various projects to invent their own system, and yet easy to use or develop new filters with. FFmpeg is already well-known for its libavcodec. This proposal is to implement a high quality video filter library for FFmpeg, where it can be easily used by other video-related software projects.

1. http://svn.mplayerhq.hu/mplayer/trunk/DOCS/tech/libmpcodecs.txt?revision=15625&view=markup
2. http://xinehq.de/index.php/hackersguide#AEN864
3. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
3. http://www.virtualdub.org/filtersdk

AC-3 was created to support multi-channel high quality sound. It mostly contains five channels (Right front, Center, Left Front, Right Rear and Left Rear) and one special channel for low frequency effects, but the number of channels may be various. Since early 90s it have been used in many cinemas, it also used on DVD-Video and HD-DVD. Because of the popularity of this codec, it is very important to make good implementation of it in projects such as ffmpeg. And that's why I decided to work on ac3 decoder.

JPEG2000 is an image compression standard. It was created to supersede the discrete cosine transform used in standard JPEG. The new algorithm is based on the wavelet transform. The lossless - by the use of reversible wavelet transform, and lossy - by the use of the CDF 9/7 wavelet transform. The main advantages of the standard are:
- superior compression performance (much higher than in JPEG, especially at high bit rates)
- support progressive transmission by pixel and resolution accuracy, which is very useful when publishing images in the Web
- flexible file format

FFmpeg is an open source tool that can convert multimedia formats. It is highly portable. Most codecs it supports are coded from scratch to provide the best performance. It is widely used in other open source projects, such as mplayer, xine or videolan.

The goal of my project is to implelement JPEG2000 encoder and decoder in FFmpeg, so that it can be used by the open source community. Although its advantages, the format has not yet become very popular. My project will surely help to change it.

During this project I will implement a decoder and encoder for Dirac
for ffmpeg.

Implementing a MPEG TS/DVB Muxer, which comforming to the specification ISO 13818-1.

To write a libavcodec decoder for Qualcomm's 'Code excited linear predictive coding' speech/voice codec as is commonly found in 3g2 and mov files, using the reference source, shared by the company while developing it and the published standard. Efforts will be made for optimizing the resulting decoder to make it usable on constrained or low end hardware.

There's a lot of room for GUI improvements in Fityk, this project aims to fix existing issues, and add some improvements to make the GUI more usable and intuitive.

I will build a front-end to freebsd-update using GTK+. It will be designed in
two parts: a daemon that waits for freebsd-update to find new updates and the
front-end proper.

The back-end daemon will find when there are updates available. It will then
tell the front-end about the updates that will display them and allow the
administrator to install them.

The back and front ends will communicate over either a local IPC or a network
connection.

The design will allow for multiple back-ends on different computers to allow
one front-end to update headless servers.

What is FreeBSD?
From the front page <http://freebsd.org>:
FreeBSD® is an advanced operating system for x86 compatible (including Pentium® and Athlon™), amd64 compatible (including Opteron™, Athlon™64, and EM64T), UltraSPARC®, IA-64, PC-98 and ARM architectures. It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. Additional platforms are in various stages of development.

How does it run?
Using a unified and integrated kernel / userland, providing a large amount of functionality to a large userbase. For any applications not included in the base system (kernel / userland), the applications must be installed via an infrastructure called "ports", which are maintained by a group of volunteers. The ports system is constructed of multiple makefiles, predefined variables, and other items.

A similar analog are packages, which are versioned tar files containing precompiled ports binaries, as well as system / userland precompiled binaries.

Issues:

Speed:
There has been a great deal of discussion on the hackers at freebsd dot org list about the speed of the package / ports database being too slow (uses standard Binary Tree with BDB). One request (the primary one) is to take the Binary Tree based storage algorithm and convert it to a Hash Table format with BDB, which would greatly increase the search / insert time, to O(c) instead of O(log(n)) or O(n) in the worst case scenario.

No unified frontend:
There currently isn't a unified frontend in ports, requiring admins / users to install either management applications that require ruby (which depend upon perl, not in the base system) and tend to be slow, or a unix shell script version which provides ports management, but tends to break periodically.

Base / ports dependencies break other ports:
There are a number of different packages included in the base system as well as in ports, and there's some confusion in the underlying ports system when it comes to which installed system to use. Some examples are OpenSSL, OpenSSH, Kerberos 5, etc. There should be some simple virtuals / entries created to the underlying ports system to allow base and ports versions of libraries / applications from not conflicting with one another.

IP can easily be tunneled over a plethora of network protocols at
various layers, such as IP, ICMP, UDP, TCP, DNS, HTTP, SSH and
many others. While a direct connection may not always be possible due
to a firewall, the IP packets could be encapsulated as payload in
other protocols, which would get through. However, each such
encapsulation requires the setup of a different program and the user
has to manually probe different encapsulations to find out which of
them works in a given environment.

The aim of this project is to implement the Super Tunnel Daemon, a
tunelling daemon using plugins for different encapsulations and
automagically selecting the best encapsulation in each
environment. Should the environment change, the user would not notice
the transition to a different encapsulation except for a small
delay. Connections estabilished within the tunnel would seamlessly be
migrated to a different encapsulation. In this way, mobility would be
supported as well, even to the extent of changing between different
physical network interfaces. New encapsulations could easily be added
in the future using the plugin interface.

The implemnation would be in C, use the tun(4) interface, multiplex
between the tun device and the encapsulations with a select(2) and
load plugins via dlopen(3).

Rewriting lockmgr support for the FreeBSD kernel

Recent analisys on FreeBSD scalability, evicted a number of kernel bottlenecks that should be solved someway. One of the hottest cames from the heavy lockmgr(9) syncronization primitive implementation*.

The project will be focused on rewriting lockmgr on a lighter basis, using memory barriers (atomic(9)) and a direct usage of the sleepqueue(9) low level interface.
This is alredy an ongoing effort, but some foundraising would speed up the development.

* the lockmgr code demonstred very fragile at relatively simple changes too

Apple's MacBook computers are nicely designed and have neat
features that other laptops don't. While Mac OS X is a nice operating
system, UNIX folks (like me) would prefer to run other operating
systems like FreeBSD.
This project aims to bring bug fixes and new drivers to FreeBSD that
would help running this OS on this platform.

Ulf Lilleengen
lulf at stud.ntnu dot no
Getting gvinum up to standards

One year ago I sent a proposal to improve gvinum in FreeBSD. Although
I did not get any sponsoring, I did a lot of work on it.
Unfortunately, none of these changes has been imported into the code
base due to lack of developers. One year later gvinum is even more
important to get up to standards, because I have experienced even
more users who have troubles with it. This is because it's not
reliable enough and not correct enough for an old FreeBSD
installation to be upgraded to the 6.x series yet. I want to change
this.

This project is about to produce a program to test some devices' network performability by emulating remote TCP endpoint. Based on prior work, the task may focus on designing test schemes and displaying the report on packet level in a comprehensive way.

Project Description

Currently, many devices in FreeBSD's source tree use excessively verbose methods of resource allocation and deallocation. Numerous calls to bus_alloc_resource() or bus_alloc_resource_any() are used to allocate resources, and subsequently, multiple calls to bus_release_resource() are used to free the resources after an error in allocation or when the device is detached.

Recently, however, the bus_alloc_resources() and bus_release_resources() functions have been added. These simple wrappers around bus_alloc_resource_any() and bus_release_resource() both operate on the same resource description, so that much of the repetition once needed to allocate and free resources can be mitigated.

My project is to update driver source code where necessary using the new functions to make the code related to allocation and deallocation simpler and clearer, while making other refinements as needed.

I will patch and test as many drivers as I can during the Summer.

A kernel module that allows copy-on-write style logging of I/O requests and can be used as a "safety net" during critical file system operations.

FreeBSD is a UNIX®-like operating system with lot of interesting and exclusive features. One of those is the FreeBSD Ports Collection, which provides easy installation, customization and management for third-party softwares. Official packages are also built from the Ports Collection. This proposal is about some new updates, immprovements and features for the Ports Collection infrastructure.

Main purpose of this project - to write extendable (as much as possible - C) code wrappers to provided by PXE and UNDI APIs to support downloading of files via TCP-based protocols in preboot environment. Goal - to introduce code, able to download and prepare booting of FreeBSD kernel from remote server via direct connection or http proxy.

The current FreeBSD's installer, "sysinstall" is more than 6 years
old and way overdue for a replacement. This project will create a graphical install & setup application for FreeBSD which aims to make use of a live on-CD system and specifics of the FreeBSD system.

Linux KVM is a Virtual Machine Monitor, part of the Linux
kernel, that uses Intel VT-x or AMD-V extensions for x86
processors to create a full virtualization environment.
This project will consist in porting Linux KVM to the FreeBSD kernel.

Since Linux KVM has a structure similar to that of a device driver
(actually, it is a device driver, from many points of view,) core kernel
changes will not be required, and the final product of this project will
be an external loadable kernel module, exporting an interface based on
ioctl() calls to a device descriptor.

Part of the project will be also the porting of the userspace client
for that interface, a modified qemu that uses KVM for host
execution.

Freenet is a tremendous project, but one of the biggest problem (IMHO) is the lack of useful and interesting content.
But after a reflection, this situation seems to be logical : If it's easy to insert or download a movie, currently it's hard for a common user to publish a site or a blog.
On the web everyone can easily express himself in a CMS, Wiki, Blog, Podcast, ..
On Freenet, the only solution is to create a Freesite, but a lambda user can't do because it requires to know HTML, CSS, etc.
This situation may change with Freekiwiki, but a wiki is made for collaborative content, so it's not adapted for many usages like a personal site.

Many social systems (such as links on the Internet) have the small-world property, but also a power-law degree distribution. This means that some nodes have many more peers than others. This can be a risk for a network with respect to targeted attacks, but also something I think one has to partly accept in case that the Freenet system should allow for adding trusted connections just as in the real
world. It's hard to put constraints on this.

I would like to take the existing work/simulations that have been done and see if it could be extended to a network that either has finer details or are in some sense more alike to the structure of either wider models or to the current generation process (setting up connections via an irc channel should for example give quite clustered networks with few long links, perhaps also with very varying amount of degrees of the nodes). Having a large number of connections may be relevant to study for avoiding bottlenecks in the network.

The creators of Freenet tried to enhance the security of the system by envisioning all forms of DOS attacks. There still however exist some ways in which an attacker may affect the system through some variant of DOS. For my project, I will try to provide a DOS resistant link level encryption using the Just fast Keying(JFK) key management protocol.

Denial of service attack can be directed at Freenet by the attacker in several ways.
1.Insert a large number of bogus files into the network to attempt to fill the network’s storage capacity.
2. Distributed DOS attacks can be launched by the attacker by using several zombie systems to simultaneously launch smurf attacks( spoofed broadcast ping messages to flood the system) because there is nothing to prevent the attacker from using any number of ports on a single host pretending to be an extremely large number of nodes.
3. The attacker could also modify all messages that pass through him by generating false RequestFailed or TimedOut messages to DataRequests or sending messages with extremely large amounts of data.

JFKi provides active identity protection for the initiator and no identity protection for the responder, whereas JFKr provides active identity protection for the responder and passive identity protection for the initiator. By superencrypting the authentication packets with the symmetric key in each node’s reference, we make JFKi resistant to the attacker.
Link level encryption by means of the Just Fast Keying (JFKi) protocol significantly reduces the chances of analyzing network traffic when the communication link operates continually and carries a significant level of network traffic. JFKi will be DOS resistant because it will resist CPU/memory exhaustion attacks on the network, unaffected by Man in the Middle( MITM) attacks because nodes will authenticate other nodes and most importantly, protect the anonymity of the user which is the unique feature of the Freenet that sets it apart from other P2P architectures.

The JFKi protocol will be implemented in Java (Freenet is written in Java) so that it can be incorporated into the Freenet source tree. Having studied the Freenet architecture and the several cryptographic algorithms in the past, I am confident of completing the task within the stipulated time.

The original Freenet documentation is present here
http://freenetproject.org/papers/freenet.pdf

The scope of this project is to add DVB CAM support to Freevo.
Kaa.record, the recording component used by Freevo, is based on the
GStreamer framework so this will require adding the support to
GStreamer and then integrating the work back in Kaa.record.
When this project will be completed, Freevo will have a rocking DVB
CAM support. Also all the other GStreamer based media players will
be able to integrate this new feature with little effort.

There is an Eclipse plug-in for OCaml programming. The plug-in is a part of EclipseFP project(http://eclipsefp.sourceforge.net/index.html). However, the plug-in provides only a few features and looks being not maintained for two years.

I propose better plug-in, which provides following features.

1. Integrated build system, which recognize the dependencies between modules
2. Code editor, which provides simple code formatting and refactoring browser
3. Integrated unit-testing support

MySpace is a popular social networking site used all over the world. In May of 2006, MySpace released their own proprietary instant messaging program, MySpaceIM. The goal of this project is to reverse-engineer the MySpaceIM protocol and implement support for it in Pidgin's libpurple (formerly Gaim's libgaim) library, allowing Pidgin users to have full access to the MySpaceIM network.

A preliminary proof-of-concept Gaim plugin implementation is available at http://xyzzy.freeshell.org/gsoc/myspace-gaim-prpl-01.tar.gz, implementing the following:

- Parsing most of the protocol
- Logging in using RC4/SHA1-based authentication
- Sending messages, by numeric userid or username
- Receiving messages, currently only by numeric userid
- Some buddy list support (show all users on buddy list as online, by uid)

Gaim's SSL (Secure Sockets Layer) support is currently incomplete. Several protocols, notably the MSN and Jabber instant messaging protocols, use SSL to communicate securely with the chat server to prevent harvesting of password data, hijacking, and eavesdropping. However, Gaim's current solution to SSL support is something of a hack; in order to sidestep the problem of key management, Gaim simply "takes the server at its word" and does no certificate verification.

I propose to add a certificate management system to Gaim. This will provide increased security by allowing the user's Gaim client to keep track of the certificates of the services she uses, alerting her to unrecognized certificates, and allowing her to verify and add them to the trusted list.

SILC (Secure Internet Live Conferencing), another secure chat protocol that Gaim supports, would also benefit from the addition of a key manager. If time allows, I intend to extend the certificate manager to be useful for SILC keys.

PROJECT DELIVERABLES:
(SILC-related parts somewhat optional)
- A unified "Certificate Manager" interface within libgaim through which the various public-key-using systems can export key/cert management.
- A corresponding "Certificate Manager" dialog for the GUI.
- Appropriate extensions to the SSL and SILC interfaces to provide a protocol-specific "key management API" for each, through which the trusted keys/certs databases can be modified.
- Management interfaces, implemented through the Certificate Manager interface, that allow the user to control the key/certificate stores of SSL and SILC.
- (Possibly) A set SSL certs to ship with Gaim and initialize the cert store.

Gaim is a popular instant messaging client with support for more IM protocols than most people have fingers. In recent times, it has been suggested that Gaim development has stagnated; for example, the MSN protocol implementation lags behind that of a number of other clients, and there is no voice or video support.

Telepathy is a communications framework built around DBus. Connections to IM servers, text conversations, and voice calls (for instance) can be implemented with a number of separate processes, interacting via the session bus. This approach allows each component to do one thing well, rather than requiring a single monolithic application to provide every piece of functionality. It also allows any new UI to reuse the existing connection managers rather than having to reimplement every protocol itself.

Currently, there are only five released Telepathy connection managers. Some of these are said to be superior to Gaim's implementation of the same protocol, while others are more rudimentary. On top of this, Gaim supports a range of protocols which are totally unavailable within the Telepathy universe. I propose to implement:

    * a Gaim-based Telepathy connection manager, to provide Telepathy clients with access to the full range of protocols supported by Gaim.
    * a Telepathy protocol plug-in for Gaim, to give Gaim access to Telepathy implementations of protocols in addition to Gaim's own implementations. This would also allow other desktop applications to interact with Gaim's connections without needing Gaim-specific code in each application or application-specific plug-ins in Gaim.

=======
Overview

A prioritized list of deliverables is as follows:

1. Shortcut Keys Overhaul
2. Sound
3. Logging Improvements
4. Buddy List Options
5. Documentation of my changes
6. Crashing bug fixes (if time permits)

========
Shortcut Keys Overhaul

The shortcut keys need some serious work. I will build an independent interface made available with a command line option to catch basic keystrokes. To provide running customizations I add an interface within Finch to bind keystrokes to predefined actions. Finch will be able to detect both 8-bit meta and ESC sequences. If time allows I will also add the ability for Finch to detect that the user is unable to send commands due to key binding issues and then provide a way for it to grab a group of basic keystrokes to allow the user to navigate.

====
Sound

I frequently run Finch inside a screen session in the background, and it is very frustrating when I miss someone who tried to talk to me. Since it's not a GUI and doesn't have the ability to pop up a notification, the best way to resolve this problem is with the use of sound. I will add the ability to customize sounds for different events, similar to many existing IM programs. I will also make sounds customizable on a per-buddy basis similar to how you can program custom ring tones for different people in your cellphone.

=====
Logging

The logging features are another feature I will improve. I will build on the same basic ideas found in Pidgin's logging tools. Though there are a few ideas I want to add.

I will add the option to search through all conversations instead of just searching them one by one, or even searching them over a range of dates. There will also be the option to search from a list of logs from different users. From there we can add an array of search capabilities to better search the logs.

===============
Basic Buddy List Options

There are a few options to the buddy list that I think are missing. I will add the ability to hide/show empty groups and to hide/show buddy details.

===========
Documentation

I will document my work for users and developers in LaTeX and thus provide a way to output the docs in a variety of formats.

==============
Crashing Bug Fixes

If time allows I will work on some bugs that cause Finch to crash. Some of these are related to chatting over GoogleTalk and causing a segmentation fault when the program attempts to exit.

My name is Eoin Coffey and I'm applying to continue working on the mono-loader plugin for Gaim.

After the 2005 SoC I submitted my patches for a basic mono-loader to gaim and they were accepted and committed shortly thereafter.

Currently the mono-loader is sitting neglected in the Sourceforge's shiny new SVN repository.

I aim to fix that.

The plan breaks down into improving the stability of the plugin, possibly improving mono to make the first task easier, and planning, generating, and packaging .NET bindings for Gaim.

The main goal is to update MSN protocol and its features support in gaim, and producing quality code ready to be included in mainline gaim. The areas of improvement will be the MSNP13 branch completion and stabilization, SOAP handling simplification, direct P2P file transfers, and extra features supported by the MSNP protocol such as storing the display picture and personal message on the server, so it is the same everywhere the user connects.

The goal of the project is to design a virtual classroom plugin for gaim. The instructor can add the students as buddies in his own classroom group on gaim. Whenever the instructor runs the classroom, the students can connect to it to get benefits from his lecture .. The main features will be a white board where the professor can draw & write and chat facility(through gaim). He can also show them some videos if required.

Everyone know what does “IM” stand for? And almost all of us use messengers in everyday life. We can chat with out friends, parents, colleagues or even boss, we can just simply chat or have an important conversation – it doesn't matter actually. In the end, the only thing that matters is the information - only what we or our interlocutor typed. So it's rather useful and comfortable to have access to chat log anytime.

May be you think that it’s not a big problem. Let’s imagine you have one home computer and another home computer or your personal working place at university, work or anywhere. So you need to synchronize your logs (which can be very important). It's a very common problem of many IM users (I am not the exclusion).

The goal of this project is to extend existing logging subsystem of Gaim, popular multi-platform instant messaging client. This extension allows to safely store your logs on different type of repositories and synchronize your logs with remote ones. With this extension you don't need to copy valuable information form messenger to external device no more. You can forget about mailing your own logs to your own mailbox to have access to them from some other place. With this extensions you can stop worrying about the hardware failures - because what ever happen with you computer, your logs will be safe. Another minor goal is to allow user to convert their IM message history to Gaim log.

The current implementation of Gallery2's search functionality suffers from poor performance, a problem particularly pronounced for large datasets because indexes cannot be used to improve efficiency. The solution to this performance and scalability problem is to use DBMS agnostic full text indexing for searches. Furthermore, the current search implementation does not support complex queries (such as queries containing boolean operators) or effectively support even basic relevance-based ranking algorithms. The use of a full text index and an enhanced query parser could offer improvements in both these areas.

Gallery 2 currently supports a number of databases for storage backend including MySQL, PostgreSQL and Oracle. SQLite is a new flatfile database system that is fast, simple and easy to use and is now included by default in new PHP installations. By adding support for SQLite to Gallery 2 as a storage backend it increases the number of people who will be able to easily install and use Gallery.

Deliverables for this project:
  SqLiteStorage class that extends GalleryStorage

  Implements SQLite Version 2 using ADODB and SQLite Version 3 with PDO driver added to ADODB

  SqLiteStorage will have to handle ALTER TABLE which is missing from SQLite by making a new version of the table and copying all the data.

  Add SQLite to DatabaseSetupStep class in Installer

  Test and Pass all 2200+ Unit Tests

Visit http://codex.gallery2.org/Gallery2:SoC-SQLite_Gallery_2_SQLite_Backend for more information about the project.

The idea of this project is to develop a 'Web based
Image Manipulation' module for Gallery. Gallery is a
very good package for managing images.There are a lot
of things which we can do with gallery.But
surprisingly gallery does not come with many Image
manipulation options.There are some basic operations
like flip, rotate and resize.But it would be great if
we could have a bigger set of image operations built
into gallery so that even users without any image
editing software on their computers can manipulate
their images before they take prints.

Improve the Current Exif Extraction G2 Plugin, adding database storage support(and searching) along with property editing for a subset of suitable items.

Currently G2 has an Exif plugin, which enables read-only access to embedded metadata in image files, this plugin also provides an admin interface to select which fields should G2 display on Basic/advanced view mode. Every time a user request to view an GalleryPhotoItem via the core.ShowItem view/controller, the underlying Exifer lib parses the original file Exif/IPTC Attributes, and the Exif block is embedded on the view, displaying the user-selected subset of the picture metadata.

There are several drawbacks of this approach. One of them, is the amount of load that impacts the server when the underlying Exifer/JPEG libs parse metadata entries, something really noticeable on big files. Other drawback is the unability to search such parsed properties just from the database.

I want to solve those current G2 issues, and provide additional functionality by implementing a base Metadata Interface, and two backend support modules for it, in a way that the backend can be chosen by the user, as already happens with the Graphical Toolkit. I also want to implement a MetadataEditor for Gallery, capable of setting metadata fields on a per-item and per-album basis, something similar to what the customfield module provides. Beside this, I want to extend the current Exif module capabilities to copy a selected field gathered from medatada to a GalleryItem field after adding new media to the Gallery. This will allow a G2 user the possibility to mirror any gathered metadata property to a user-selected property of a GalleryItem, replicating previous exif module functionality in a flexible, user-customizable way.

There has been previous attemps to do this, however, no further advance has occurred since then, and the issue is still active on the tracker, being also one of G2’s most requested features.

The RTL array data dependence analyzer was written specifically for swing modulo scheduling (SMS) implementation in GCC. It is overly conservative, because it uses RTL alias analysis to find intra- and inter-loop memory dependencies. It also assumes that the distance of an inter-loop memory dependence equals to one.
 
I propose to improve the quality of data dependence analysis on RTL via propagating the information from Tree-SSA dependence analyzer. The saved information will be used in construction of data dependence graph for SMS. It can also be used for other optimizations, e.g. scheduler.

I would like to contribute to the Fortran front end of GCC by implementing some missing features from the Fortran 2003 standard, primarily concentrating on the ones concerning object orientation. In particular I would like to focus my efforts on the implementation of:
- procedure pointers
- type-bound procedures
- (and possibly even more ...)
Depending on the time it takes to reach the first two aims, I would try to implement some more Fortran 2003 features, where the object-oriented features would be on top of my list (e.g. type extension, inheritance, polymorphism, type-bound operators), since I think that the lack of object orientation is the most serious deficiency of Fortran 95.
I chose the two primary aims because type-bound procedures are at the heart of object orientation, and procedure pointers are a good first step towards type-bound procedures.

My idea is Open Mutliprogramming Interprocedural Analasis and Optimalizations (OMP-IPA). Multithreaded programming has become very important and I think that GCC should focus more on this subject. OpenMP implementation in GCC is on very basic stage, and there is still a lot of things to do. In my opinion my project (OMP-IPA) may improve GCC's posibilities and fix some bugs.

The GNU Compiler for the Java programming language includes a front end for the compilation of source code to JVM bytecode. The original front end has evolved over time, to be eventually replaced in early 2007 by a front end based on integrating the Eclipse Compiler for the Java programming language in order to allow gcj users to utilize features from the Java 1.5 language specification in their code.

I would like to integrate the OpenJDK javac compiler, into gcj in the same way. That would allow gcj to easily track the next batch of Java programming language changes planned for Java 7 as they are introduced in the javac code base, as javac serves as the reference implementation for Java programming language (bytecode) compilers.

The project would entail :

1. Making javac build and run on gcj & GNU Classpath, building upon the work done by Andrew Haley and Andrew Hughes.

2. Porting the GCCMain wrapper for gcj-specific behavior (compiler options, error output style, etc.) to wrap javac's functionality and integrating it into the gcc bootstrapping process.

3. Integrating gcj+javac into the gcj and javac regression test suites, in order to shake out and fix potential regressions in the jc1 bytecode-to-native-code translator in gcj, as well as the integration code.

4. Adding support for the stack map attribute in gcj, which was introduced in JSR 202 and implemented in javac for Java 1.6.

5. Rebuilding Fedora's, Debian's or Gentoo's Free Software Java programming language based packages using the gcj+javac combination in order to detect and fix potential regressions in real-world code.

Most scheduling approaches consist of two steps: computation of sets
of available instructions at the current scheduling point, and
choosing one of them to become the next instruction. This approach is
used in GCC compiler in current implementation of list scheduler
(known as Haifa scheduler) and new approach under developing –
selective scheduling. While most activities aimed at improving
scheduling quality are trying to increase number of gathered available
instructions (such as above-mentioned selective scheduling, treegion
scheduling, improvements of region formation), choosing step plays an
important role too. Current implementation of scheduler uses static
priorities, based on critical path heuristic, which is known to behave
well while scheduling single basic blocks and become worse when
expanding scheduling boundaries to extended basic blocks or regions.
This project aims at developing a new priorities system, which would
consider not only the critical path, but other possible exits from
scheduling region and their probabilities.

The SDF parser will parse SDF files, that are described in Standard Delat File format ( a generic SDF file, no FPGA or ASIC preference). It can be invoked by the '$sdf_annotate' system task and match paths with the specify paths actually available (via vpi) in the design.

This task is made in C and can be loaded as a VPI module, that is inoked by the VVP engine during the simulation time. The property EDA tool, Modelsim, from Mentor Graphics, is used to validating the implementation and a comparative report is attached by the end of project.

Debugging HDL circuit descriptions is a challenging task as many events in hardware systems occur concurrently. One of the best ways to debug such systems is by viewing the simulataneous changes in logical waveforms within the system using a waveform viewer. Gtkwave is an open digital waveform viewer commonly used in academic and industrial settings. I propose to fix some usability issues in gtkwave, such as reloading waveform dumps while gtkwave is running and improving inter-run compatibility of stored waveform configuration files.

These days there are several different CMS and Weblog packages freely available for website owners to download and install. Because of this it is imperative that a software package create a warm and fuzzy experience for those who are installing and administering it. The current Geeklog installation procedure may be seen as daunting by novice website owners. The several steps that are involved in the setup process makes it likely that a user will become discouraged during the process, abandon the installation and move onto try other weblog software. Additionally, it is a hotspot for errors if a user makes a syntax mistake in the config file during the setup. My suggestion for a more automated process should solve most of those problems and present a more elegant installation experience.

Geeklog 2 is getting to a stable and usable state. The new Geeklog 2 core allows for most major functionality to be added in via a plugin structure.

Geeklog 2 needs a working plugin implemented to ensure all the various
API's built into the kernel (SOAP, Event Management, etc) are working as designed.

The core to most CMS engines is article management and as such Geeklog 2 needs an Article plugin.

The Article plugin will allow users to post articles to be displayed on the front page of the site. It will be written in PHP, Xhtml and Xml.

To accomplish the task of creating this plugin a core class will be written to house all the needed "main" functionality, such as submission functions along with any hooks to make it compatible with future plugins (ie. a media plugin).

The finished plugin will deliver a very flexible article submission system, complete with richtext editor, SOAP inteface, AJAX (which will allow the plugin to be usable without javascript, but if the clients browser supports it will allow more advance enhancements), media hooks, options to configure how the article is displayed, and automatic article aging.

My proposal for SoC is to develop a comprehensive Web Services API for the Geeklog content management system. The purpose of this API would be to publish and update stories and comments using a desktop application, import data into the Geeklog system or export data into a standard or well-established format such as RSS or Atom. This would also entail a re-organization of Geeklog's code internally, and the development of an API layer to handle the flow of information between the web service, the website, plugins and the database.

Cytoscape is an open-source network visualization and analysis software.

A network is composed of nodes and edges. Those elements can have different values associated with them, known as attributes. The user can search and retrieve a list of nodes or edges according to a specific attribute’s value. Currently, The search is carried out one attribute at a time. To perform complex queries, involving multiple attributes, the search should be repeated for each attribute; then the result sets can be merged into a final result set. Wildcards can be used only for terminating a value.

I will introduce an improvement to Cytoscape that will enhance the search capabilities to allow searching on multiple attribute fields with the use of logical operators and wild cards.

The search interface includes a text line, into which the user types the query. The intuitive query syntax uses the form attribute:value. Logical operators (AND, OR, NOT) can be used between the query parts, resulting in a search on multiple attributes. The use of wildcards anywhere within the value will provide additional flexibility to the search strategy.

An important usability feature in wikis is the ability to examine changes made by others. The same principle goes for wikipathways.org. Simply showing an old and new version of a pathway side by side may work, but usability could be improved by giving better visual indicators of what has changed.

I intend to develop a standalone utility that takes two pathways in GPML format, calculates the minimal difference, and turns this into an SVG image that clearly visualizes the differences between the two pathways. I'd like to create at least two possible visualizations: transparent overlays and a two-pane color-coded layout.

I've created mockup images of what I think this could look like here: http://ftp2.bigcat.unimaas.nl/~martijn.vaniersel/gsoc/ . I want to implement two different visualization styles simultaneously to get a better idea for what ideas are good and bad. User-testing should determine the best of the two and I want to make that part of my project. Subsequently I intend to integrate this application both into wikipathways.org and PathVisio.

++++ Pathway Editor for WikiPathways.org ++++
To facilitate easy and user friendly pathway editing, I propose to rebuild PathVisio to create an embedded pathway editor, that can be included in the WikiPathways.org web pages. A user should be able to activate this editor with a single mouse click making the editor start within seconds. The editor should be light-weight, user friendly and have no other dependencies than the user's browser.
For more info see: http://conklinwolf.ucsf.edu/genmappwiki/Google_Summer_of_Code_2007/Thomas

Graphs (networks) are one of the main utilities for visualization of biological data. Standard algorithms for graph layout are good enough for some applications, but knowledge of domain is sometimes a necessity for proper analysis of the represented data. Main purpose of this project is to combine advanced graph layout algorithms with semantics of represented biology data in order to get the best representation.

Most work in Gentoo revolves around the maintenance of the ebuilds in the portage tree. This work is divided up amongst either individual maintainers or herds. An individual maintainer or a herd is responsible for committing bug fixes and version bumps for the packages that they officially maintain. A single maintainer or herd cannot take on more packages than they have time to work on. As a result, the number of packages that can be well maintained in portage becomes limited by the number of developers. Second, should a maintainer become absent, his packages will not be maintained. Sometimes users will submit ebuilds with version bumps for bug fixes, but not have them committed to the tree until the maintainer returns.

I propose a system that helps overcome these disadvantages. My project will not require a banishment of official maintainers and herds, as there are advantages to such a scheme. My project's goal is to allow Gentoo to expand its capabilities to better support a large number of packages. I propose to create a web interface where users and developers can collaborate on a list of packages maintenance tasks. The tasks in higher demand will be at the top of the list. Users can register, mark that they are working on a task, submit their work, and wait for a developer to review and commit their work. Developers can do the same, with the exception that they will not have to wait for another developer to commit their work.

This interface will effectively allow users and developers to flexibly to take on tasks without needing to search for a maintainer or herd to do the task. This interface can allow for the ability to have packages in portage that are not maintained by a single herd or maintainer, but instead are maintained by the whole community. If an issue arises with such a package, the issue will be put on the task list, and solved by the large number of people who might care about the package.

Another thing that the interface will allow is the ability for herds and maintainers to list tasks that they cannot do. For example, the kde herd is in need of more maintainers to fix a number of outstanding bugs. With the interface, the herd can submit the bugs and see a response from capable people who do not have time to be an official maintainer, but have the time to fix a bug or two. In sum, the interface will allow Gentoo to communicate specific work that needs to get accomplished to the community.

GNAP (Gentoo Network Appliance) is a toolkit to build small
Gentoo-based distributions for embedded devices or old PCs.

It consists of 3 packages: gnap, gnap-dev and gnap-ext (all in
dev-embedded). Gnap provides the gnap_overlay script, which is used
to build customized images (disk image or cd image). Therefore it
takes a prebuilt GNAP core and "overlays" it with customized
configuration files. Gnap-dev provides gnap_make which can be used
to build customized GNAP cores and extensions for existing GNAP
cores. Gnap-ext provides gnap_remaster, which is used to extend GNAP
cores with extensions. It is easy to get a simple system running
using only the gnap and gnap-ext package and GNAP is also flexible
enough to allow the user to build complex images with all kinds of
special software using gnap-dev.

Unfortunately, all of them are only available for x86 and/or amd64.
It is only possible to build images for x86 compatible systems. This
is a big limitation, since lots of embedded systems are not x86
based, but ppc, arm, mips or mips64. And since GNAP can run off a 16
MB flash drive and is very customizable (a smaller gnap is possible,
a totally different purpose is possible) it is interesting for all
kind of devices. Or it could/would be, at least.

The goal of my project is to integrate cross compilation support in
GNAP, include support to build images on platforms different than
x86/amd64 and to include support and create documentation for at
least one specific embedded board. This probably also includes
cleaning up the codebase, fixing bugs to get gnap working out of the
box (the current gnap in portage needs some love) and maybe
expanding/clarifying existing documentation.

Improve the usability of GNAP/Catalyst-based distributions by developing a Cisco-like CLI framework, as well as basic configuration-plugins for it. The goal is for this layer to be flexible enough as to empower other more high-level layers to sit on top of it.

Specifications:
*Separation of the CLI as a system, from the code that enforces user configuration commands.
*Modular architecture: New configuration commands and modules can be inserted/removed/updated at anytime on a running system.
*Supports local (console) connections and remote (network) connections with optional authentication.
*In-line scripting language embedded in the CLI interface, with ability to activate/deactivate.
*System configuration for each configuration plugin is reflected internally in XML files.
*Command output is natively XML, with later being XSLT (or otherwise) translated to human readable format to be displayed on the console. XML allows for easy layering with other Configuration Interfaces (such as Web-based or Remote GUI).
*Integration with “GNU Screen” to support multiple parallel local CLI sessions.
*Arbitrary configurable privilege modes, with arbitrary configurable commands associated to each of them (USER, EXEC, ...). A command can be registered in many privilege modes.
*Optional authentication for each of the privilege modes. Hash-based authentication.
*Arbitrary configurable configuration modes (configure terminal, router rip, interface eth0, ...) this resembles a tree directory structure with different command visibility at each node. A command can be registered in many configuration modes.
*Superset of the functionality provided by a Cisco-router in terms of CLI versatility.
*Real-time informational messages on the console in a push manner, for evens such as interface link state UP/DOWN.
*Escape mechanism that allows the user to enter shell mode and conduct debugging, information gathering or manual tweaking of the configuration.
*Optional component. The user must be able to deactivate it and be able to configure the system manually or by other means. While active, other means should be avoided, except if they can interact with the CLI API.
*Bounded command length, or unbounded with the last element repeating arbitrary times (or limited by the handling function).
*Finally some basic configuration plugins should be provided mostly as a proof-of-concept, and to encourage user community to contribute, and also as a guidance on how plugins should be implemented.

Gentoo is a huge project with many developers and big and complicated infrastructure. All new developers must know how to inter operate with others without problems and collisions and how to fully use all tools and services before they are accepted and granted access into CVS repository and other parts of infrastructure. To make this even more complicated there are several kinds of developers (...) having access to different infrastructure and needing different knowledge (...) and skills.

Historically all this was checked by quizzes (sets of questions ensuring that recruits read and understood documentation). (...) Everything was coordinated by emails.

This process of course does not scale too well. The biggest problem is that quizzes were too static (...). Also questions need to be adjusted as the infrastructure changes. Maybe even the whole process should be centrally managed by this system (...).

The equizApp is designed to fix these problems and make everyone's life easier. The most important part of it will be the question and answers database. (...) The second part will be individual quiz generator (...) with some export options for ready quizzes (with answers or without). The third part (optional: if Gentoo Recruiters want it) will allow Recruiters and mentors to fully manage whole quiz process for the given recruit (...).

I propose to do equizApp as an application driven by web browser (and possibly some scripts if needed), installed on some Gentoo server, written in PHP (...) or Python (...), using MySQL or PostgreSQL and integrated with Gentoo's LDAP for user authentication. Also I think it is good idea to use some framework to avoid mixing presentation with logic and bloating everything with heaps of (X)HTML code. Of course the requirements and design and especially feedback from Gentoo developers can change these plans.

My goal is to keep it as simple as possible (KISS) so everyone will be able to change and adapt it as process it models changes (something that probably slowly happens anyway, as with all real life "business" processes). The most important part is the model of the whole process and workflow and right design that fits it. Then features can be easily added when needed. This way the application can serve well for many years with only minor improvements.

Working with a large network of machines involves, among other tasks,
dealing with jobs in a comprehensive and as-simple-as-possible way.

The job subsystem is one of the most complex parts of SCIRE, given
that it has to deal with several scenarios that may turn a simple job
into very frustrating experience. This SoC project aims at working on
this subsystem so it can handle from simple tasks as jobs for a single
machine to more complex duties as per-profile recurring jobs with
error handling. This will be achieved trying to make client and
client-server communication as simple as possible delegating most of
the work to the server application.

Create Python bindings, associated documentation and test cases for the Paludis public API, and allow subclassing of Paludis classes using Python.

Most current version of my application:
http://dev.gentoo.org/~peper/soc/application.txt

The basic operations on visuals, as defined by GGI, are intentionally limited. It's impossible to define an API for all possible graphic features because of the variety of hardware, and the fact that graphic needs are constantly evolving. Such an API would be bloated and quickly obsolete. The GGI answer is to implement only a simple set of universal features, and leave the rest for extensions.

In this project I start with an existing extension framework called libggigl.And extend it with OpenGL API, allowing GGI applications to easily use OpenGL for drawing.

We can improve XGGI (the fork of X server which uses GGI at backend)
by implementing various latest developments in X.
 1. Available X extensions should use libggi functions for h/w
    acceleration.
 2. Update RandR support.
 3. Implement Composite extension.

The project goal is to replace most git scripts written in shell or perl languages, with a more portable and faster builtin C versions.

Many git commands are currently implemented as scripts, since they are easy to program. In order to run the program in other systems, a Bourne shell and a Perl interpreter need to be properly installed, resulting in a harder development and use on other platforms or systems.

Many projects has been converted to builtin code already, and the structure of the code simplifies that task. At present, there are about 10 perl scripts and 32 shell scripts in the Git code implementing essential Git commands, like "git commit", "git merge", "git clone", etc. It has been estimated three days for converting the smaller cases, and a couple of weeks for the larger ones, so most of the scripts would be replaced with this project, allowing easier port of the program to other platforms.

With Google Calendar, you can create and add your schedules and your family and friend's , add events mentioned in Gmail conversations.You decide who can see your calendar and which details they can view. You can create invitations, send reminders and keep track of RSVPs right inside Google Calendar.

Enabling connectivity to the google calendar from evolution . The Aim is to create a google calendar backend that allows to read and write through the GData Interface.Evolution will have a offline read-only support google calendar , and a online read/write support .

The Gdata provides a protocol for reading and writing data on the web. GData uses standard XML-based syndication formats either of Atom or RSS. It also has a feed-publishing system that consists of the Atom publishing protocol plus some extensions (using Atom's standard extension model) for handling queries.Client applications can view and update calendar events in the form of Google data API ('GData') feeds.Evolution can use the Google Calendar data API to create new events, edit or delete existing events, and query for events that match particular criteria.

Currently the Gnome desktop is missing some great multimedia content creation applications. Jokosher is already fairly good but apart from that everything else is just in the beginnings.
This project will be mostly audio-oriented and would help Buzztard, Jokosher, Marlin and to some degree Pitivi to become better by providing a foundation in GStreamer. Some starting parts are already there but for example many audio effect plugins are missing and some GStreamer parts, although being there are half-implemented or suboptimal.

The goal of this project would be to improve the current situation by providing some more audio effect plugins, finishing some unimplemented GStreamer parts and adding some missing elements.

Brave New X11 World

With the changes to the X.org windowing system with version 7.3, a range of new possibilities is available for the Linux desktop platform in regards to input and display configuration. This Summer of Code project aims to take advantage of these changes to significantly enhance the GNOME Capplets for configuring input devices and displays. Upon the completion of this project, GNOME should be able to run entirely on hot-plugged input peripherals, with advanced options such as individual key mappings and settings on each device. GNOME users should also be able to easily detect all attached display devices, configure their resolutions, refresh rates, and relative positions, as well as store these settings in profiles, which can be changed at the press of a button.

For a formatted, PDF version of this application, please visit the following URL:
http://www.designerglasssigns.com/private/soc/application.pdf

One of the major features required in any kind of desktop deployment is the support for lockdown, where users are barred from performing certain actions (like, for instance, printing files, or saving files to disk). GNOME already has lockdown support in a few areas (especially the panel and the epiphany web browser). However, the file manager (Nautilus) does not have any kind of lockdown support at all, and good quality documentation and specifications for the lockdown features is also missing.
The proposed project will add lockdown features to Nautilus and to the GTK+ FileChooser (to ensure a consistent user experience, as well as complete implementation of relevant lockdown policies). The lockdown features would cover filesystem access and modification permissions. Moreover as a part of the project, I would implement a mechanism to define items which will be shown on users' desktops, such as links to common web sites, launchers for programs, or links to commonly-used files such as forms or reference material. I would also document how lockdown and preconfiguration work, which can be used as a reference for administrators and deployers. The last, but in no way the least item in the roadmap is a plan to create a spec for the proposed lockdown on Nautilus and the GTK+ filechooser (probably this should go to first :-)).
The project will involve modifying various GNOME modules (Nautilus/GTK/GNOME-VFS/GNOME-Panel/GNOME-Desktop/etc), written mostly in C. The relevant GUI tools (Sabayon/Pessulus), which are written in Python will also be extended as and when required.

PiTiVi is an open source, non-linear, non-destructive video editor that shows great promise. While it is currently barely usable, it has the potential to be transformed into a robust, powerful media authoring tool. I want to help 'kickstart' the project by implementing the minimum set of features needed to attract a community of users, and be considered a functional video editor.

PiTiVi is designed to be flexible enough to offer at least two UI views, called 'Timelines'. Currently these are 'Simple', aimed at novice users, and 'Advanced', offering more professional features. Most of the features proposed here would be implemented in the Simple Timeline, and would include: editing and trimming support, project file load/save support, and transitions. Optional goals would include a media capture interface, jog/shuttle support, and contributions to the Advanced Timeline.

Synopsis
Most GNOME users access and discover new information using a web browser. The broad goal of this project is to develop a framework for Epiphany that will enable GNOME users to quickly, easily and accurately recall this information. To that end, this project will focus on three specific goals:
1. Develop a high-level design for unifying the storage, visualization and management of user bookmarks and browsing history.
2. Implement a robust and efficient backend store for bookmarks+history objects on top of an indexing framework like Tracker
3. Integrate the currently separate bookmark and history managers to create an intuitive User Interface (UI) for viewing, searching and managing bookmarks+history.
If time permits, an optional goal is to provide a simple high-level wrapper API over Tracker's DBUS API (libtracker) for accessing and querying bookmarks+history from Epiphany extensions and other GNOME applications.

Benefits to Epiphany and GNOME
Epiphany currently has an excellent topic-based bookmarking system which is the best in terms of ease-of-use among all browsers available for GNOME. By integrating the current system with browsing history, this project will bring several useful and novel features to Epiphany:
1. Quick and easy interface for viewing, searching and bookmarking history items.
2. Powerful free-text search over entire "contents" of bookmarks+history URLs as well as filtering based on metadata attributes such as page visit date.
3. In the long-term, facilitate new Epiphany extensions and GNOME applications for visualizing and organizing bookmarks+history, e.g. Browseback [3]
4. A private trusted system (unlike online systems such as Google search history) that the user can rely on for increasingly common problems (e.g. “Where did I see it before?”)
 
In addition to Epiphany, the GNOME desktop will also benefit immensely from a central object store for boomarks+history. An object store maintained by the browser itself will have more fine-grained and accurate metadata. This could be leveraged by desktop search tools for providing more relevant results. In addition, applications such as Deskbar could easily integrate handlers for bookmark+history search using the Tracker API (or the optional high-level API).

This project will implement a new document editor for the Project Mallard using Python and XML.

This new document editor is called Foie Gras and will be an asset for doc writers. Foie Gras will effectively hide the XML tags and will give the user the ability to focus more on the documentation task rather than having to divide their attention on both XML and documentation.

There are many solutions to share one or more files, from setting up a Samba share, to a personal directory in a HTTP or FTP server, they have one big common flaw: they do not “just work”. As a consequence people often use services relying on an external server (such as email and chat), or removable devices. In some cases it is not even reasonable to do server-based communication, as is the case of meshed networks.

Moreover systems like Samba or FTP are useful at home or work when you want to permanently share a folder but often people just want to quickly send a file to some specific person. For that you do not want to first put it in your shared files (making it available to everyone, which you might not want so you need a password on it etc.) and then tell your contact that he/she can find it there. Just right-clicking on a file and using "Send to" (through a nautilus-send-to back-end) to just send this file to that person is a lot nicer.

An ideal system should automatically discover other users in the neighborhood, list them and let the user choose who to send files. The system should also work without any configuration, without the need to tell one’s IP address, and without requiring any operation from the administrator, such as setting up a server or configuring a service.

I want to develop a program to satisfy those needs enabling users to easily send and share files over a LAN. My plan is to work on the telepathy-salut connection manager adding support for file transfers, on top of that I'm going to write an easy-to-use GTK-based GUI to show available contacts and to initiate and accept file transfers. The GUI should also manage authorizations in a user-friendly way, without bothering the user with technical details about the involved certificates.

Recently Xavier Claessens, the author of gossip-telepathy, started to work on grapevine, a modular version of gossip using Nokia's mission control. A good idea would be to work on it adding file transfers capabilities instead of writing a separate GUI, this way other protocols could benefit of my work.

With the recent X Window System changes, a lot of features are being added, and
the whole world will need to adapt to these changes.

One of these changes is the addition of multiple-pointer support in X.org 7.4,
that will allow a whole new set of applications that were never made
before, and will also make multiseat easier. When X.org 7.4 gets released
people won't be able to make full use of its new features if there is no window
manager that also manages multiple pointers.

And to be able to use all of these new features, the window managers will have
to be adapted. What I am going to do is to fully integrate metacity with MPX,
write a document describing the new features that window managers should
implement, and how to do it. The aim of this document is to help developers to
implement multiple-pointer support on their own window managers.

Also, in the process of adding multiple-pointer support to metacity, problems
might be found and there might be the need of new features/protocol calls, so I
will be able to detect them and report/correct them before xserver 1.5 is
released.

By the end of summer we expect to have a window manager that brings the new MPX
features and a document that helps everyone integrate their window managers to
work with MPX.

Podcasters often interview guest via VoIP, some even have their regular presenters communicating via VoIP when physically being in the same room is impossible. In these circumstances it would be useful to have VoIP integrated in to an audio editor, such as Jokosher. This would allow each person participating in the conversation to be recorded as a separate track/instrument, allowing for much easier mixing and editing of the resulting audio.

 This would be achieved through use of the Telepathy communications framework, allowing Jokosher to make use of multiple VoIP protocols such as SIP and XMPP (as used by Jabber/Google Talk).

 I believe this feature would be unique amongst all Free and proprietary audio editors and would be useful to a large number of podcasters.

Synopsis

Overall project goal is to improve GNOME Bluetooth stack so that it has more functionality and all the features are easily accessible to user. Current gnome-bluetooth functionality would be made available from Bluetooth applet (BlueZ GNOME applet). Support for OBEX FTP server would be introduced and existing gnome-bluetooth code would be refactored. Gnome-vfs OBEX FTP module would be further improved.

Benefits

Currently there are at least three separate attempts at making Bluetooth experience in GNOME better: BlueZ GNOME apps, gnome-bluetooth and gnome-vfs-obexftp. This project would unify all of these (both code base and UI) as well as improve overall functionality.

Success criteria

* gnome-bluetooth code should be refactored to loose libbtctl dependency;
* A working OBEX FTP server should be implemented;
* All the Bluetooth functionality should be accessible from Bluetooth applet;
* All configuration options should be available in Bluetooth manager.

This project aims to automate account management in GNOME infrastructure. Currently a lot of things are handled manually. With this project account team will only trace the work flow of account creation and only do final decision.

The project is to develop version 3 of art.gnome.org(AGO).

The main objective of the AGO project is to be an artwork community server at users disposal. As such, Users are the ones who should decide what they want to see. They should have an user-centered experience and feel they are part of the community. Naturally artwork developers should also be encouraged to participate actively with their work. Without them there is no artwork. Thus, users should be able to comment and review developers works and consequently developers must be able to receive such feedback.

Currently, in the Gnome desktop, it is generally impossible to glue together applications in a manner similar to what AppleScript does. There are good examples of scripting within apps (see: Gimp's Script-Fu), but it doesn't allow the easy gluing together of applications, automating workflows such as "Insert data into Gnumeric, Create a chart in Gnumeric, save to file, and convert to EPS for use in LaTeX".

    This scripting will be the counterpart, to technologies like Apple's AppleScript and KDE's Dcop, and hopefully will eventually interoperate well with DCop.

    The idea was inspired by Hubert, in this blog post:
  http://www.figuiere.net/hub/blog/?2006/04/16/397-desktop-scripting

I should like to put forward a proposal to write a VoIP and video call client for GNOME based upon the Telepathy framework. I am a first year Computer Science undergraduate and have been an enthusiastic user of GNOME since my introduction to Linux four years ago. I have always wanted to contribute to the open-source software community and I believe that I now have the necessary foundation of knowledge and programming ability to do so. I have followed with interest the development of Telepathy and should like to create an application which will allow the GNOME community to benefit from the new opportunities presented by this project.

My application will provide a GTK front-end to Telepathy to allow audio and video calling via the XMPP protocol. I will create the client's UI by constructing new GTK widgets that will form part of the Grapevine project. Grapevine aims to gather together both Telepathy back-end functionality and UI components from which current and future GNOME applications may be developed. As well as being a showcase for the power of Telepathy, I hope that this client will be act as a proof of concept for these widgets by demonstrating how Telepathy may be fully integrated into the GNOME desktop through Grapevine. A simple interface for the setup and troubleshooting of both webcams and microphones will also be included.

To get involved with two such great projects as GNOME and Telepathy would be most exciting for me. I think that such a project would be invaluable to me in my education as a programmer and that GNOME would be even greater by the inclusion of an application such that I have proposed.

Gnome Scan aim to make scan as simple as print for both users and developers. Gnome Scan was started during the Google Summer of Code 2006. The project continued his development, including moving to Gnome SVN, distributing in Ubuntu/universe, translating in several languages.

However, Gnome Scan shows its structural limits :

 * Hard coded very limited processing (only rotation was implemented)
 * Hard coded scan option set (resolution, area, …)
 * Hard coded UI. The dialog wasn't build depending on device
 * No scan from file (useful for importing PDF with one image per page).
 * Some duplicated code
 * Quite buggy SANE handling.

Also, since the beginning of Gnome Scan development, some other technologies have evolved :

 * HAL is receiving SANE support. SANE provide HAL fdi (in CVS) and HAL addon for monitoring buttons.
 * Gegl implement very nice and efficient processing pipline.

Waiting for Gnome SVN account, i redesigned Gnome Scan in order to fil the lakes and take advantage over new technologies. This summer, i will implement Gnome Scan ng specification.

SUMMARY
-------

The GNOME documentation system is under reconstruction (Project Mallard). As part of this, there is need for a WYSIWYG editor that lets anyone (both authors and contributors) to create and modify documentations easily (codename: Foie Gras).

Within this project I would create a module for F-Spot that would make face detection on the pictures, and tagging of the detected faces possible. It would also give grounds to a future, automated system (developed after the SoC), which would give a new level of photo organization. Faces could be automatically recognized and sophisticated queries could be performed (i.e. integration with Beagle).

The following link contains the full proposal :
http://facedetect-f-spot.googlecode.com/files/fspot-proposal.pdf

The idea is to develop some features that will improve the usability in the Gnome Desktop. The goal is to implement a Desktop Voice Control System. The system consists in an application that will be monitoring the audio input( microphone ) and when a significant audio signal has been detected, the software catches, processes and recognizes the signal and then executes the desired action over the Gnome Desktop. In a set of actions could include maximize, minimize, close the active window; open a specific program; switching from one desktop to another; among others. The software will be implemented in C language in conjunction with CMU Sphinx, which is an open source tool, created to recognize and decode audio files in word list files. The software will be developed as a Gnome applet.

The original proposal is available here:
http://live.gnome.org/SummerOfCode2007/Ideas

Some people already track the status of their finances with spreadsheets. They might, for example, keep a record of all withdrawals and deposits from a bank account in a spreadsheet and use the sum feature of their spreadsheet application to keep track of the balance. Such users may wish to migrate their data to GnuCash but would find the task of manually copying all of these entries into GnuCash daunting.

Virtually all spreadsheet applications can export to CSV format. Therefore, I propose the development of a dialog for GnuCash to import spreadsheets in the form of delimited files. The dialog will accommodate various forms of delimited files by allowing the user to specify the meaning and order of the columns in the file, the column delimiter, and the character encoding. It will attempt to be as transparent as possible by showing the user the consequences of each configuration change instantly. To minimize the work the user has to do, a guess at the file's format will be made in the hope of providing reasonable default settings. When the user is satisfied with the configuration, the user will click a button and the transaction data will appear in the user's account.

The Aim of this project is to build automated Gui test suite for GnuCash, using dogtail, my proposal is not only building this test suite but also to make it an environment that make it easy to create, maintain, understand GnuCash test cases, and considering all precaution that should be considered for this type of projects, consider the best practice in those systems, The Test suite will also monitor the quality of the application, by monitoring e.g.the response time of the dialogs.

The aim of this project is to implement CD-ROM booting support in GRUB2. First, an INT13 calls driver will be implemented to provide access to the boot image. This has the drawback that it relies on a relatively new compliant BIOS (some BIOSes are buggy). Second, a full ATAPI driver will be implemented to do the same function, hopefully on any setup (including older and buggy BIOSes).

The purpose of this project is to extend GNU Make with user defined method for deciding when a target is out of date. Persistent will be also added because it is necessary to make this useful, for example, for using MD5 sums for checking if a source was modified since last compilation.

I propose to develop GNU Mailutils[1] TLS encryption (Transport Layer Security) to all client-side code, particularly to 'mail' utility (IMAP and POP client) and Sieve filter. Client-side encryption will secure fetching/sending of e-mails from/to remote connections and will allow to use mail services which don't work without encryption (like Gmail for instance). I have already implemented TLS to the server-side code (pop3d and imap4d), which is now part of the Mailutils framework, as well as I did some other miscellaneous contributions. My work will be based on using GnuTLS library[2] as the encryption backend. GnuTLS is part of the GNU project.

References:
[1] http://www.gnu.org/software/mailutils/
[2] http://www.gnu.org/software/gnutls/

In the last years, Java has seen various efforts in the direction of Desktop integration, but the various implementations still lack important functionalities, and this is especially true on GNU/Linux and the other FLOSS systems, though luckily GNU Classpath is pioneering in this area, paying already a particular attention to the Desktop integration.

One of the area still uncovered by this integration is that of the sound editing/streaming.

Many solution exist for native applications, but they are not accessible to java programs and in a standard way, and this lead to poor performance, duplication of code and an overall bad user experience, GStreamer is a versatile framework for creating streaming media applications, and is the default framework used by the Gnome Desktop Environment and by most distributions; javax.sound, aka Java(TM) Sound API, is a low-level API for controlling Input and Output of sound media and is the standard API for use by all the Java applications.
 
GStreamer is so widespread as default and provide most of the functionality that the Java Sound API requires, that makes sense to implement javax.sound peer classes that natively use GStreamer as a backend for data transport and audio format handling, enabling so
Java desktop application the access to Formatted Audio data and
sound pipeline creation directly via Gstreamer.
 
Part of the Goal is also to develop simple applications and Mauve
Test classes, to show the validity of the project and the final results.

The GNU Hurd needs a library that abstracts the idea of a character
device to ease the clean and efficient implementation of their
corresponding translators. It has been recognized as needed for a
long time and some tasks have been stalled because of it's lack.

Not only could such a library enable quicker and cleaner
implementation of many translators that directly corresponds to kernel
implemented devices, such as keyboards and mice. It would also allow
this for character devices that are layered on top of other devices.

The goal of this project is to design, implement and document
this library, which will be called `libchannel'.

The basic idea of this project is to extend Portable.NET to support generics in the C# compiler and the Portable.NET Virtual Machine based on the ECMA standard 334 and 335.

My proposal is aimed at providing two functionalities to GNOWSYS. First
is to provide a model which can be used by a Web browser, Gnowser or an application to make concept maps of the knowledge base stored by GNOWSYS. Second is to provide a single unified framework for importing
and exporting the knowledge base and its organization in RDF, OWL, XTM,
CL, KIF, LISP, Prolog, CNL and other such languages for seamless interoperability.

My idea is to design and implement a synchronization interface for the phpGroupWare project. External devices such as cell phones and PDAs will be able to keep a synchronized copy of parts of their phpGroupWare data, for example your calendar.

I would like to finish GNUstep's Key Value Observing implementation and implement bindings. I am interested in this because KVO and bindings would lead to faster, easier application development, cleaner code, and bring GNUstep closer to compiling the majority of Cocoa code without modification.

Key Value Observing is necessary to implement bindings, and would increase the flexibility of GNUstep's KeyValueCoding implementation. Bindings support would eliminate the need for most outlets and controller code that deals with updating the status and value of UI controls while reinforcing the separation between Controller and View in the Model-View-Controller design pattern. As most modern Mac OS X applications take full advantage of KVO and Bindings, a GNUstep implementation would be a huge step toward source-level compatibility with Mac OS X.

My work would include creating the NSController, NSArrayController, NSObjectController, and NSValueTransformer classes and adding bindings support for existing classes, for example NSTextField, NSPopUpButton, and NSProgressIndicator.

Improving the GNUStep AppKit components will help to develop GNUstep and increase compatibilty with Cocoa.
I shall be Implementing a modified NSBitmapImageRep class to write GIF, JPEG, PNG & PNM files. I shall also be producing implementations of NSDatePicker, NSLevelIndicator and NSCell classes.

However the main body of the project shall be focused on examining, finishing, rewriting and generally cleaning up the whole Text System, and profiling it.

This will benifit GNUstep by having more features in the framework, as well as a clean Text System, suitable for testing.

During application development, fairly often appears a nessesity in sockets use. Applications written using
Google Web Toolkit aren’t the exception. Unfortunately, most of browsers are devoid of possibility to connect
with other computers by means of sockets. So when such necessity appears, developers have to write a server-side
implementation (Java Servlets, PHP, ASP.NET or something else), which could realize connection with other computers
by sockets and transfer received data to a browser, using, for example, AJAX. Unfortunately, such solution has it’s own
disadvantages because of the server-side can’t notify the browser of data receiving. Standard and somewhat slow
decision: a browser is querying new data every n seconds. Also more interesting solutions exist, such as Comet and
Continuation, but they also have some disadvantages. But the main shortcoming in such realization of socket support
for browsers is the necessity to write a server-side, which will essentially load a server while numerous users use it.

I suggest to realize socket support in Google Web Toolkit on a browser level using GWT Socket module.

There are some means to realize it:

1. Java Applets
2. Macromedia Flash
3. XPCOM (Only for Firefox)
4. ActiveX (Only for Internet Explorer)

Solution based on Java Applets.
- Needs Java virtual machine and Java Plugin.
- Could run on any platform in any browser supporting Google Web Toolkit.
- It is possible to use wide Java capability.
- Includes writing small Java Applet, which will fulfil connection by means of sockets.
- Applet is easy enough to realize.

Solution based on Macromedia Flash.
- Needs installed Macromedia Flash plug-in in client's browser.
- Could run on any platform in any browser supporting Google Web Toolkit.
- It is necessary to write LiveScript code, which will fulfil connection by means of sockets.

Solution based on XPCOM.
- Doesn't need any additional plug-ins.
- Could run in FireFox browser only.
- Demands knowledge of XPCOM.

Solution based on ActiveX.
- Needs an ActiveX component, which will fulfil connection by means of sockets.
- Could run in Internet Explorer only.
- Demands knowledges in ActiveX component writing.

Taking to account that Java and/or Flash are installed by almost every user, Socket module will include both these solutions.
The module will be flexible enough in order to the developers’ possibility of adding solutions based on XPCOM and ActiveX,
in case of need if necessary.

The module will consist of Flash and Java applets, corresponding communication between applet and GWT, and clean enough
interface for developers.

Sockets module will essentially facilitate GWT based application development, which need a possibility to work with sockets.

phpAspect is a PHP language extension to implement Aspect-Oriented Programming (phpaspect.org).

The goal of this project is to write a phpAspect plugin for eclipse in order to make people able to use phpAspect easily in their projects.
This plugin will have the following features:
* Support of phpAspect syntax
* Embedding phpAspect
* The vizualisation of cross references.
* The vizualisation of advices into the business logic.
* The vizualisation of code refactoring effects in the functioning of aspects.

Google's web toolkit is a great tool for writing large web applications that depend heavily on javascript, and since the primary functionality for gadgets is written in javascript it seems reasonable to use GWT to write gadgets. For my summer of code project I would like to extend GWT to make the process of writing gadgets in it less of a challenge. I would like to add functionality to ease the process of writing gadgets for multiple frameworks by allowing writers to focus on functionality rather then implementation.

It is my understanding that the Google Web Toolkit would be much benefited by having a tool that "could examine two versions of a set of Java classes and report on interface changes that affect user code," as per http://code.google.com/p/google-web-toolkit/wiki/GWT_GSoC . I propose to complete such a tool within the timeframe of Google's Summer of Code 2007.

As a Ph.D. student in Software Engineering / Software Analysis and Understanding, I have ample experience with various algorithms and data structures relevant to analyzing object-oriented source code and runtime behavior. What is more, Java has been my first language of choice for implementing analysis tools, which is directly pertinent to the needs of the Google Web Toolkit.

I am slightly puzzled by the suggestion to use Java reflection to solve the problem, as that is sub-optimal in my opinion, and in fact is a step that can be skipped. A better solution would be to employ direct comparison of the Abstract Syntax Trees (AST) of the two versions of Java classes, and report the corresponding differences. I propose to develop a tool that will:

- Build the Abstract Syntax Trees of the Java classes in question.
- Compare pairs of Abstract Syntax Trees to encounter any changes between two versions of a set of Java classes.
- Report the identified differences in a concise structure that can be either examined by a human, or passed on to automated tools.

Further capabilities can be included in the tool as suggested by mentors and as time permits.

In today's world, where almost every bit of information is available online, where people communicate via the Internet and develop open-source projects in Internet communities, a stable and feature rich network stack is absolutely required. One, that besides supporting current technology, is able to adapt to future trends, including security and mobility. We want to provide the best experience to users, and within the open-source spirit by being connected allow them to be an integral part of new developments as well.

   Haiku's current network stack, which is implemented in C++, is presently giving it's first steps. Some initial IPv4 support has been implemented, as well as some UDP and TCP. Although this initial code has been enough to complete some basic operations, some standard support is still missing. A few additional features could also be added to allow a richer experience, specially considering a future of mobile IP hosts communicating securely. Some of the crucial points to be dealt with presently, identified by both the development community and the author, include:

   * IPv6 support -- Although IPv4 is still the de facto Internet protocol, both enterprises and education networks are starting to migrate to this new Internet Protocol which introduces a larger address space, mandatory multicast and security (IPSec) and end-to-end mobility.
   * ICMPv4 and ICMPv6 support -- a host should both have a proper behavior in IP networks, generating errors whenever required, and be able to optimize it's communication by discovering the MTU between hosts, etc.
   * Multicast support -- IP multicast has a wide range of uses, from allowing applications to deliver their content to a large set of receivers with minimal effort and excellent scalability; to allowing new kinds of auto-configuration and discoverable services to be implemented, such as ZeroConf.
   * Stacked destinations / end-points -- to allow the usage of transparent security (IPSec) and mobility (Mobile IP).

For this GSoC application, I intend to finish the design and implementation of an O(1) scheduler originally written as an Operating Systems class assignment. The approach used to select threads is pretty different from existing O(1) algoritms, and it has shown very promising results compared to existing O(n) algorithms and scheduling policies (as expected). Comparison with existing O(1) implementations is on the TODO list.

The design and implementation must be finished to take into account thread blocking, real time constraints and CPU affinity, and of course it must be benchmarked against the current O(n) Haiku scheduler and, preferably, also against other existing O(1) implementations, for example the one found in the 2.6 Linux kernel series and also the ULE and CORE series of FreeBSD schedulers.

Isochronous stream is one of the 4 USB transfer type that is missing from Haiku. Devices like webcams or usb audio cards are based on this transfer type, and therefore it is not possible at the present time to use those type of devices.

Implementing it would increase the number of devices supported on Haiku.

IEEE1394(FireWire) is high speed, low cost Serial Bus suitable for use as a peripheral bus. Current Haiku operating system lack of support to FireWire. My work is porting FreeBSD FireWire stack with mass storage and DV support to Haiku. My work will focus on the following tasks:

1.Transaction layer driver. Asynchronous and isochoronous transmission support. Protocol standard: IEEE1394-1995 and IEEE1394a-2000

2.Link layer especially OHCI driver. Protocol standard:Open Host Controller Interface v1.1

3.Add support for DV cameras. Protocol standard:IEC61883 and SBP2

The Haiku Operating System finally reached the point where binary compatibility with BeOS is no more much of a problem. The only obstacle left for the user to enjoy the goodness of this very important feature is the .pkg package format. Many applications made for the BeOS platform use and prefer this type of data storage. At this stage of development, the existence of a .pkg compatible package installer would be a powerful addition to the system.

PackageInstall will be a simple .pkg package installer. It will be mostly based on the BeOS default pkg installer, offering a user friendly, lightweight interface. It will be written in C++, using the Haiku API.

Precaching is an important feature for filesystem caches. The performance of the applications at the user-end can significantly increase with proper precaching module in place. Haiku file cache has an API for precaching. But the current launch_speedup module is very basic and simple. No precaching is implemented. I propose to implement the precaching algorithm for launch_speedup module.

In Haiku the dirty blocks remain in VM until there is an explicit call to 'sync' system call. This might result in data loss because of power outages or sudden system crashes. In the light of the above issue I also propose to implement aging policy of the file system caches.

HP iPAQ h5000 series are older, but not rare devices, which are, except for their native operating system, capable of running linux. They are working very well when it comes to linux 2.4 kernels. But these kernels are already slightly older and more recent software doesn't seem to run without required modifications with them, e.g Hardware Abstraction Layer requiring sysfs will not run correctly without some sort of emulation layer.

  There is also linux 2.6 kernel running on these devices, but there are still some things missing to make these devices ready for production use. Aim of this project is to complete 2.6 kernel support, ideally to A+ support according to handhelds.org evaluation. This includes support for virtually any device available on h5550 device, which is almost superset of hardware found in these devices.

  If there will be enough time, sleeve support could also be on plan, eventually even accelerated driver for mq1132 graphics chip.

The goal of this proposal is to redesign the way Darcs handles conflicts and automatic merging to solve the current practical and theoretical problems with conflicts. Informally a conflict happens when two patches cannot be automatically merged into one repository.

Darcs suffers from several flaws in the way it handles conflicts between patches. Improper conflict handling in Darcs results in problems such as exponential time required to merge changes or failure with an error message. When this happens the user is left to manually merge and patch their repository which frustrates users and defeats the purpose of version control tools.

The problems with conflict handling were believed to be rare but large projects such as GHC have shown that conflicts are more common in practice than originally believed. It is commonly believed that improper conflict handling is the biggest flaw of Darcs and must be fixed as soon as possible so that Darcs may reach its potential.

By using a graph structure to store the relationships between conflicting patches, less re-computation will be involved in each merge and the decisions the user has made in the past about previous conflicts may also be stored. Storing this data will allow Darcs to handle future conflicts efficiently and correctly.

An important goal of this work is to maintain the current level of abstraction for the user. The user should be able to continue working with repositories as sets of changes. The modifications to the user interface should be minimal while the changes to the user experience should be great.

I propose to reimplement the type checker used in both the nhc98 and
YHC compilers, using Constraint Handling Rules (CHR) and based on work in the Chameleon project.

* Motivation

The current typechecker used in both compilers seems to be largely
unmaintained, is difficult to understand and extend, and is
occasionally wrong. Many common type system extensions to Haskell 98
remain unsupported.

In light of the upcoming Haskell' report that is likely to extend the
type system in a number of ways (eg MPTC+FD, rank N types [1]), it is
becoming increasingly important to the maintainers that the
capabilities of the type system remain up to date, and to provide a
simple and easily extendable platform for further research and
experimentation with type systems. From a larger perspective, it is
important for the good health of Haskell as a language that we
maintain a certain amount of variety in implementations and offer
viable alternatives to GHC.

The goals for the type checker are:

1. To be simple and easy to understand
2. Easy to extend
3. Provide good error messages.

Generalizing the Parsec interface with a monad transformer for ease of use
for the programmer, and get the best out of the new fast ByteString IO layer.

The Glasgow Haskell Compiler (GHC) links the executables it produces statically to Haskell packages. This not only wastes disk space but also leads to an increased loading time for the program itself and GHC Interactive.

This application is about making GHC able to link to shared libraries of Haskell packages, reducing disk usage and loading time. Shared libraries are also shared in memory by Linux, hence the effective memory usage of a set of concurrently running Haskell programs is reduced.

Requirements for shared libraries in GHC:
1. Build object code as relocatable PIC code.
2. Link PIC object into shared libraries.
3. Patch GHC to make use of this shared libraries when producing exectuables.

--Introduction--

 The success and penetration of a programming language or platform often hinges on the tools that are available for use with that language. For example, a widely cited reason for the popularity of Microsoft's .NET platform is because of the ease of use offered by the VisualStudio IDE. Even more obscure languages have benefited from a robust tool-set. Scheme, a language noted for its use in education, has Dr. Scheme[1], an IDE developed and used with the How to Design Programs textbook. Haskell itself has likely observed a boost in popularity with Darcs, a flagship product of the community that is used throughout Haskell development now. Given this, I propose to further develop GuiHaskell[2], an existing effort to develop a useful Haskell IDE.
 
--Status--

 At the moment, GuiHaskell is capable of running a Hugs and GHCI environment inside of it. However, one cannot switch between the two without editing the source and re-compiling. Most of the toolbar buttons are also non-functional.

I propose to add the following capabilities within the three month allocation:

* Capability of running main Haskell implementations, e.g. Hugs, GHCI, Yhc, nhc, Jhc, etc.
* Functioning toolbars and menus.
* Create a framework for linking the application with existing Haskell tools, e.g. debuggers, profilers, etc.

The following features will be looked into and worked on if there is additional time (I estimate that there will be):

* Profiling.
* Cabal integration for building and installing packages.
* Hoogle support.
* Support for a debugger.
* Syntax highlighting.
* Simple editor integration: open up an editor separately and jump to the appropriate line on an error in the REPL. Hyperlink to the editor instead of embedding it.
* Editor embedding: external editors can be integrated into the application using GTK's Plug and Socket widgets (see PIDA[3] for example). This would allow the use of vim and possibly emacs within the IDE (a desirable feature because it would decrease the learning curve for users of those editors).
* Editor-pane and REPL-pane: DrScheme uses an interface where the main pane contains a standard editor that can save and open files and a secondary pane contains the REPL. When the evaluator is run, the file opened in the main pane is run and any functions or variables defined can be used from the REPL. This design would fit the Haskell development cycle as well.

Here I will list some additional niceties that could be added to the project after the summer of code:

* User's manual and in-depth documentation of features.
* Expand IDE to include advanced features such as class/type browser panes and project management like other full-featured IDEs (e.g. Eclipse, VisualStudio, etc.)

--Preliminary timeline--

Planning: Decide whether to extend PropLang, re-write using Gtk2Hs, or extend using Gtk2Hs. (I have taken the third approach in initial patches because it is easiest for now)
Week 1-2: Support for adding multiple Haskell environment and the capability of switching between them.
Week 3-4: Get menus and toolbars functioning to the level of WinHugs at least.
Week 5: Investigate how to integrate external tools into the IDE. It may be helpful to look at the approaches of other IDEs (e.g. PIDA, Eclipse, etc.) as well.
Week 6: Work on integrating cabal tools.
Week 7: Work on integrating profiling tools.
Week 8: Additional time for integrating cabal/profiling. Start on hoogle integration or syntax highlighting.
Weeks 9 and beyond: Add additional features (e.g. editors, debugger, etc.) and streamline the existing ones (e.g. one-click operation).

VideoIO Framework for GEM

This framework should be implemented via a plugin architecture (the various i/o modules are to be loaded at runtime).
It will be made available on all major platforms that are supported by pure-data: linux, os-x and windows.

The following points should be realized:
* read/write video from/to firewire
* read/write from/to files with various de/coding libraries
* evaluation of libraries and desicion which one will be used (quicktime, directshow, libxine, mplayer, aalib,...)
* implementing Video4Linux Loopback Device

I would like to write the latex plugin for ikiwiki, since I have to use latex very often for university (I use it to wrote my summaries).

Nice features would be:
 - add support for exporting the page to pdf via latex (or to native tex files)
 - add support to upload latex code which is then displayed on the side (good for chemistry & mathematics) (as img or html, I have to look what is better)

Problems I see:
 - if people use packages which are not on the server (some chemistry packages are not yet available in debian/other distris)

The Wikiwyg editor will be integrated into ikiwiki allowing users to edit pages with the click of a button. It will allow them to edit wiki pages just like they were using a word processor.

In wiki pages you are allowed to edit text and save it but nowhere it is allowed to add images and also display some of their information automatically. Ikiwiki has done some work in this area but it has huge scope for improvements. It will be very useful for users to be able to add or edit their images, comments etc:- with the same ease and efficiency as is done for text in a wiki.

I plan to implement automatic extraction and displaying of information like resolution, exif metadata in ikiwiki. I will also add functionality to create thumbnails, allow commenting using AJAX, rating and embeding watermark. Some Javascripts will be used to enhance the image browsing features in ikiwiki.

There would no longer be need of a completely different site for uploading images like flickr. You can have your text documents and images at the same place in ikiwiki.

Contact: http://www.arpitjain.com

My proposal contains various tasks that would enhance the user's experience of Inkscape's text tool, including addressing issues with font family variants, implementing advanced character insertion, legalizing flowed text, improving character and paragraph styles, and redesigning text user interface elements. A subset of these tasks will be completed at the discretion of the mentor, on a priority-per-item basis.

At the moment, effects on paths are possible through the use of external extensions. These extensions are not 'live' in the sense that they are not interactive: if a modification to the effect is required, one has to recreate the situation before the effect was applied and run the extension again. Live path effects will make many of these extensions interactive and live on-canvas. For example the path along path effect will hugely benefit.
Within this project, the underlying infrastructure will be created as well as a common framework and a couple of effects, including a basic UI to apply these new live effects.

Even in the framework of 2-dimensional vector graphics and illustrating, it is often desirable to edit objects 'in a 3D fashion', for example when drawing perspective representations of 3-dimensional scenes (as technical illustrators would want to do), but also in a lot of situations when creating 'pure' artwork.

The proposed 3D tool will render this possible in Inkscape in a very intuitive and flexible way, by allowing the user to draw 3D boxes with arbitrary perspectives, freely move the vanishing points/perspective lines, move the boxes 'towards a vanishing point' (preserving the perspective), possibly rotate them 'in 3D', and many more things.

Once this basic tool is available, its functionality can be used to implement a wide range of further enhancements with regard to 3D aspects (like extruding objects, drawing on inclined planes, etc.).

See the accompanying web page http://www.rzuser.uni-heidelberg.de/~malbert for details.

This goal for this project is to design and implement a complete user interface for SVG filter effects.

Inkscape was built purely as a vector editor – a GUI, you might say, for SVG. But the need has arisen for raster capabilities within the Inkscape application. Previous to this capability, the user would have to perform such raster post-production in a different application, such as the GIMP or Photoshop. Often this may not be anything more complicated than a punch/explosion effect or a windswept filter. This can be accomplished by integrating these effects, especially those provided by ImageMagick, directly into the Inkscape interface. The results will not be SVG, unfortunately, but they will be bitmaps, as the user desires.

Mentor: Ted Gould

I want to enhance the Network Diagnostic Tool (NDT) in several
directions.

First of all, I want to design, test and implement the new detection
algorithms awaited by the community. This include new duplex-mismatch
detection algorithm and new congestion detection algorithms. I am
going to create the semi-automated testing system to check new
proposals. I will prepare the detailed reports from the testing phase
and choose the best set of new algorithms for the integration with the
NDT sources.

The second area of development will be connected with improvement of
the logging system. I will further modularize the logging system and
create the possibility to use different logging front-ends. This
include the databases and network-based protocols. Moreover, I will
create the enhanced post-processing tool to allow administrators
easily review the historical test results. I think this new tool
should be written in Java using SWING to create the GUI. However, I'm
opened for the possibility to write only text-mode post-processing
tool.
    
The third thing I would like to be done during the summer is the
Microsoft Windows port of the web100clt. I know, that some
administrators use this console tool for the scripting purposes.
However, The I2util library used by the NDT cannot be compiled under
the cygwin development environment. So the only options is to use
different cross-compilation method, or modify the I2util problematic
parts (IPv6 support).

I would like to apply for the Chrolog project with Internet2. I intend to use my previous experience with TSC timers and clock synchronization in LANs in order to develop a user-space solution for obtaining fast, accurate timestamps within a known error budget. I would also like to improve the methods used in maintaining an accurate system time.

Note: This is my second version of the application, modified after receiving feedback.

Network performance measurement in high speed networks is highly important once problems to users are alike to occur. It happens mainly because the expectations of the users are defined based on quality factors and network is measured based on quantifiable variables. This fact tends to difficult the way that the network performance is showed to the user of interest. Normally user is worried if he or she can download a file in a good quality or can understand a voice conference he or she is having with another user. The users expect to have the similar perceptions of the network when they are downloading a large size file or when they are using the Internet for multimedia communication, like voice, video or both together. They care about having similar quality they are used to consume on these kinds of services not served by data networks, like the quality of phone services served by the Public Service Telephony Networks (PSTNs) or the quality received on the television systems. The users are expecting to know if there is quality to run the application they want to run and not really if the network is having some specific delay or packet loss.
The problem for Network Operation Center (NOCs) operators is to discover which factors for each kind of traffic affects the quality perceptions of the user. The question is how to represent these variables in an easy way and in quality perception so NOC operators may easily act upon a problem and present to the user if the quality of the network is good for defined kinds of applications.
Measuring metrics in an ad hoc mode is worthless. Alone, the network metrics represent only a big amount of numbers with no sense and no qualitative information interesting to end user may be obtained from them. These metrics need to be contextualized to the pattern of traffic they are meant. Using some kind of baseline technique, it is needed to create a pattern behavior of the metric on normal condition to be able to NOC operator to observe ranges of quality in these quantifiable variables. After this, the traffic should be qualified in ranges that will permit a NOC operator to inform the quality of that kind of traffic. Then, metrics may be correlated to observe how one metric influence others.

The Java Standard Edition class library[1] for Jikes RVM is provided by the GNU Classpath project, which focuses on the creation of a Free Software[2] clean room implementation. As part of Summer of Code 2006, I provided Classpath with the necessary API interfaces and a VM layer for implementing java.lang.management, which allows the running virtual machine to be monitored and controlled either locally or remotely. This year, I propose to provide an implementation of the VM layer for Jikes RVM, where such code will enhance the collation of research results and provide a uniform layer for comparisons.

Abstract
========

JDWP & JVMTI are standards introduced by sun to uniform the way JVM[s] are debugged/queried. They are not mandatory nor do they form requirements to comply with the JVM standard. Here I propose to enable those standards in the Jikes Research Virtual Machine. enabling those standards would greatly help the development/research process of the Jikes RVM itself as well as the applications that runs on it.

Keywords:
=========
Debug protocol, Java, Virtual machine, JDWP, JVMTI.

Motivation and Background:
==========================
Jikes is a Research Virtual machine developed by IBM. Jikes was released as an open source project and follows open source development model. It lacks conformance to the JDWP/JVMTI standards. They are not part of the JVM specifications.

Jikes RVM optimizing compiler was originally designed for Power PC. Having 32 registers, register pressure on Power PC wasn't a big issue but the performance of the register allocator was. Given spills and fills were rare the trade-off suggested that linear scan was a good register allocator for the Jikes RVM. When the Jikes RVM was made open source a new Intel back-end was added. On x86 number of registers had decreased from 32 to 8. x86 is architecture where the problem of graph-coloring register allocation is complicated by irregularities in the organization and use of the architecture’s register resources. I propose to implement Iterated-Coalescing Graph-Color Allocator with modifications for irregular architectures. This allocator uses interference graph to represent all program constraints.

Original proposal:
http://alexeigor.googlepages.com/gsoc2007.pdf

Vectorization is an important optimization to enable parallel code
speedup within a single processor core. Currently, most mainstream
general purpose processors provide support for vector/SIMD operations,
such as MMX in Intel processors and AltiVec in PowerPC
processors. Vector/SIMD operations are ones that perform a related
function on multiple pieces of data in parallel. These operations can
give important speedups for certain classes of application, such as
multimedia programs.

Some of the most often requested new features for Joomla! are the abilities to
nest categories in an unlimited depth, and to place content into more than one
category. The usage of the Nested Sets Model offers an elegant and efficient
solution to this feature request.

During this year's Google Summer of Code, I would like to extend the current
Node Based Scheme libraries [1] – which implement a Nested Sets Model – with a
feature which I call "Hardlinked Nested Sets". Often it is needed to place the
same item into different parent items at the same time. This is a simple task
when dealing with just one single item each time. However, as soon as one wants
to duplicate a complete branch of items (e.g. for categories with sub-items in
it), this task becomes a whole lot more complicated.

Data integrity, execution time and the forming of valid routes to such sub-items
are three major issues which need to be taken into account.

 * Data integrity should be achieved at the library level, so that whenever a
   node which has hardlinked duplicates is being changed, all duplicated nodes
   will be changed as well. The Nested Sets Model (which is used by the NBS)
   already performs non-atomic actions, and therefore requires transactions.
   So if all extensions use the provided libraries, data integrity can be
   guaranteed.

 * When the main functionality becomes implemented in the data-changing
   routines, the "Hardlinked Nested Sets" feature will have a very small impact
   on execution time of data reading functions, but requires a little bit more
   time for storing data.

 * Routes to such hardlinked sets should still contain the IDs or names of the
   original items (except for the item where the linked branch starts), to
   present unique IDs or names to the outside (important e.g. for human readable
   URLs) and inside (important for future ACL implementations).

[1] http://code.google.com/soc/2006/joomla/appinfo.html?csaid=23A1F7A6CF74EC01

My idea for JOOMLA development is making of email interface for
JOOMLA publishing. Why is email interface needed ? Quickening and make it getting easier communications and news publication. This email Interface provides function as media a author to write article in JOOMLA site without requiring to visit the the website. When article the sent to website hence publisher will get the notification by his email whether there is new article that needs immediately reviewed and published. A publisher will visit to read the the article in website or can directly agree by email.

Perhaps that idea is not really needed on country that provides high bandwidth and cheap internet payment. But it is important thing for countries that has limited bandwidth and expensive internet cost such as my country (Indonesia). For Indonesian people, it is prefer to check his email first than his website. Because it needs small bandwidth.

Currently, the web can be a real challenge to those living with disabilities. Screen readers, Braille displays and other accessibility tools convey data but yet often fail to help the user understand that data. Visual cues such as colours, text formatting, layout, graphics, etc. help to convey certain meanings to the typical user but can easily leave others behind.

Also, many tasks that are currently being performed by hand can be automated. For example, when I view a web page with a person's contact details, I have to copy and paste the information into the relevant fields of my address book application in order to save it for easy reference. The computer should be able to know which information is where on the page and do this job for me with only one or two clicks.

Web Standards and the Semantic Web are the W3C's solutions to these problems. The idea is to not only store data, but also some of the meaning that's associated with it. This will help the computer "understand" the data better and will enable it to not only convey this meaning to users in a customised fashion (in the case of disabled users) but also automatically do some tasks with the data not before possible.

Correct user of technologies such as (X)HTML, Microformats and RDF that already exists today can create improved accessibility and automation for all kinds of users. And because these technologies are royalty-free open standards, they can be implemented and used by anybody in an inter-operable fashion.

The project will focus on the improvement of the (X)HTML output from the Joomla core, going as far as possible to ensure that valid and semantic markup is used. Semantic Web technologies such as Microformats and RDF will also be utilised wherever possible in order to make an entrance into the semantic web.

Google Summer of Code 2007 – Joomla! organization

Application of Mickael MAISON


What about a Geo-component for Joomla!?


What do I mean with Geo-component?
Geographical information is becoming a key data on the Internet. Now many applications support KML/GeoRSS or geospatial tagging (Flickr, Google Maps/Earth, Drupal …).

Because of its modularity Joomla! can become a Geospatial Content Management System (http://en.wikipedia.org/wiki/Geospatial_Content_
Management_System).

With a Geo-component, I mean a component which enables the user to add geographical information everywhere in Joomla! it can be useful:
 - News/Posts
 - Comments
 - User profile

Then all this data would be publish using GeoRSS and KML feeds



How is the project composed?
This project is composed of 4 main blocs:

- The administration bloc:
Where all the configuration will be accessible

 - The user bloc:
Enabling an easy geo-tagging

- The feeds management:
KML, GeoRSS Simple and GeoRSS GML feeds

- The creation of the adapted documentation.
It will be provided as a FAQ or tutorial and will explain in details how it works.



What are the benefits for Joomla!?
Geographical data is becoming a key interest dataset. KML and GeoRSS are starting to be widely used (i.e.: the 22nd of March 2007: Google Maps support GeoRSS). Moreover these formats are being standardized by W3C and OGC and will form a significant part of the future web.
Such integration will keep Joomla! one of the more up to date applications.

Then holding geographical data of the users and of the content will enable the community to build new features like:
 - Search for users close to me
 - Groups of users based on locations
 - Languages options
        - Use Joomla! geo-coded GeoRSS or KML feeds in other applications
 - All the things the people will invent!

Building this functionality will make Joomla! content more easy to integrate into mash-ups. Providing geo-coded content feeds will be an on-ramp for developers wishing to integrate such content into their own applications.

I spoke about this project with Mikel Maron (the founder of GeoRSS) and he encouraged me to take this project forward. This functionality exists in projects such as WordPress and I am keen to see it in Joomla!.



What is the roadmap?
1. Specification and introduction into the community
My first goal will be to publish all the specification of the project in order to clarify each part and feature which I want to develop. In the same time I will start to introduce myself to the Joomla! community (until mid May)

2. Implementation:
Then starting at the end of May I will implement all the features. I will use a logical order by starting with the administration part, continuing with the user part and finishing with the generation of the feeds. All these features have to be fully supported on all the common browsers (until mid August)

3. Testing and documentation
I count on the Joomla! community to test and give feedback as soon as the modules will be developed. But I also plan to keep some time to perform tests in order to deliver the application working perfectly in all the case with all the common browsers. I also have in mind to provide documentation (I am thinking about a tutorial) of the module to enable people to extend it.



What about me?
I am Mickael MAISON a 21 years old student from the University of Teesside (Middlesbrough - UK). I am currently in the third year of a BSc Computer Programming which is a yearly internship. So I am working, as a technical consultant, until this summer in Ordnance Survey (surely the place where I get this passion about location and geospatial information).

I have developed a Chat component for the IRC Network EuropNet.org last year and I have been following the Joomla! project for a little while now so I think the Summer of Code is a good opportunity to enter completely as an active member in the Joomla! community.

Component and module is extension to Joomla. Every one can customize his CMS with add component or module into it. Developing this (component/module) is not trivial task. IDE (Integrated Development Environment) can help developer to do this work.

While manual content management and moderation has its established place in the world and on the internet, "web 2.0" has shown that there is extreme potential in algorithmic recommendation engines on both macro and micro scales. On a macro scale, it is clear from sites such as digg.com that the "wisdom of crowds" can be effectively utilized to filter content using the choices of many people to inform the content that will be similarly pleasing to many others. On the micro scale, there are a few sites such as reddit.com that demonstrate the possibilities of more personalized filtering still based on the wisdom of crowds. While the first steps have been taken in these areas there is much progress to be made.

The goal of this project would be both experimentation and implementation. While the basics of such a filter/recommendation engine are obvious, a general purpose solution requires more consideration in order to provide the desirable features in a way that works in many different environments and for different types of content. This project would aim first to implement the basic functionality of a recommendation system into a Joomla component. After the most basic functionality is implemented, more complex filtering and recommendation algorithms can be designed and tested. By the end of the project the goal would to have a Joomla component with basic digg like functionality as well as the option of more complex general filtering and personal recommendation based on content, context, and temporal considerations.

The goal of this project is to improve the Quadrilateral Remeshing K-3D plug-in
by using a different algorithm that requires less user input. The current
implementation requires the user to specify extrema points on the mesh. The
proposed alternative algorithm for the plug-in will create a quad-dominant mesh
that is aligned with the principal curvature directions.

The main idea of this project is to provide KDevelop 4 to deal with cmake projects so anyone can easily create their own cmake project. It would be great to have this feature because cmake is the official KDE 4 buildsystem and most of the KDE related projects will be using it. Being KDevelop the KDE default development environment CMake support would be an appreciated feature for the users.

Molecular visualisation is a very important area in both scientific research and education. Having good open source tools capable of producing high quality 3D images of molecules would be useful to students from high school, up to university and research level. There are very few open source tools capable of drawing and rendering 3D molecular structures. Ghemical[1] is one such application which when coupled with Jmol[2] is capable of producing publication quality images.

OpenBabel[3] is already used by many projects and allows programs to support a large array of chemical formats. Avogadro[4] is a new application and library satisfying a need in Kalzium[5] for 3D rendering of molecules as well as a wider need in the community for 3D molecular visualisation tools. Avogadro can already render 3D molecules and has basic molecular drawing facilities. It draws upon
several libraries such as OpenBabel2, Qt 4 and Eigen[6] to allow rapid
development. All core functionality is in the Avagadro library to allow other applications to easily use features implemented in the project.

Avogadro is at an early stage of development but many basic features are already present. Avogadro will be extended to add support for custom atom/bond labels, implement POVRay[7] rendering of molecules for high quality ray traced image output and add the facility to export the 3D rendered scenes at user specified resolutions. Protein ribbon views, electronic charge and interatomic distances/bond angles would also be added as well as extensive bug testing with integrated user testing and feedback during development.

Another goal is to move all calculation intensive processes (such as
geometry optimisation) into a separate thread. This would maintain GUI
interactivity during calculations and allow the program to display the molecule as its geometry changes. It would make more intensive calculations using the Avogadro program easier to implement and interact with.

[1] http://www.uku.fi/~mthassine/projects/ghemical/
[2] http://jmol.sourceforge.net/
[3] http://openbabel.sourceforge.net/
[4] http://avogadro.sourceforge.net/
[5] http://edu.kde.org/kalzium/
[6] http://eigen.tuxfamily.org/
[7] http://www.povray.org/

Currently, KDE's Kontact provides basic Journal support. However, this cannot be currently posted remotely or any more than plain-text used in creating entries. This project would improve this Journal support, integration with the KBlog blog-posting library, adding a WYSIWYG editor and other desired functionality.

KAider is a KDE4 KBabel (http://kbabel.kde.org/) replacement that I've started in January. (see http://websvn.kde.org/trunk/playground/devtools/kaider/).
My intention is to extend it to the state close to 'computer-aided translation system', i.e. tool that allows us translate more text in less time, and with higher quality.
This includes following my 'maxima': majority (if not all) of actions must be accessible from keyboard, w/o using mouse, because it takes less time to press shortcut then to do things w/ mouse.
All existing CAT systems don't support gettext format nicely, and don't have suitable interface
(eg two panel one, like in Open Language Tools, doesn't suit for translating big paragraphs we have in .po files generated form docbook; if user wants to see context, it could be displayed in a special QDockWidget, with smaller font, etc)

And, of course, they don't intagrate with KDE well.

Short list of features (over what we already have in kde svn):
-project management
-context glossary (+sipping on google translate)
-translation DB (QtSql)
-mode for merging translations for editors (QA)
-scripting API (kross)

See
http://techbase.kde.org/Projects/Summer_of_Code/2007/Projects/KAider
and
http://techbase.kde.org/Projects/Summer_of_Code/2007/Projects/KAider/Introduction

The office application for a Linux desktop has been OpenOffice for more than 4 years. During this time, a lot of files were generated in the OpenOffice specific format. With OpenOffice 2, OpenDocument started being used. This standard is allowing an old dream to become real : be independent from your office application, use what you want to use, be free. Currently, OpenDocument support in KOffice is quite good, but far from perfect. There may be missing features in KWord / KSpread, or just errors in OpenDocumment support breaking a feature or adding differences, breaking compatibility...
The aim of this project, for me, is to be able to switch to KOffice for most of my work. It means that all the OpenDocument files I can find on my hard drive must be compatible with KOffice...

Strigi [1,16], the fastest and smallest [2,3] desktop search engine introduced by Jos van den Oever, is a promising alternative to other tools like Beagle/Kerry [10].

Strigi combines stream-based content analysis with an abstract index interface [9]. The universal metadata extractor can hugely speed up the indexing phase of any desktop search engine. On top of that, it lets the Strigi daemon be ignorant about its storage backend. Currently clucene backend performs best.

Jstreams classes used in Strigi allow reading arbitrarily deeply nested files (e.g. files in a zipped email attachment) with very low CPU and memory consumption. Strigi uses parallel analyzers that can extracts different types of data from a file in parallel. Strigi and jstreams are written in C++ with very few dependencies.

KDE or any other, e.g. Gnome, applications can easily address Strigi through the DBus interface.

Strigi could be integrated into core KDE4 components [7] in the near future. Its stream trough the analyzers metadata extraction system [14] has already been merged into the KDE metadata facilities. Porting of KFilePlugins is in progress [18].

This project aims on making KDE a productive environment for Chemistry and Biology. Strigi can help chemical information to be semantically marked up, and easily retrieved.

Kfile-chemical, like all KFile plugins, are moving to jstreams directly now [15]. Kat chemical file data analyzers can also be ported. Format detection is done by chemical-mime.

OpenBabel [12] complies with Chemical MIME [4,5] and will be used to convert chemical structures to InChI strings [17] for exact molecule search [19].

To extract chemical information from text documents, like PDF or HTML, chemical text mining tool OSCAR3 [20] can be used.

You might want to look at Nepomuk [10], a group doing researching into the Semantic Desktop, which (among other things) aims to develop ontologies for metadata fields. Such will have to be developed for chemical metadata. Current status of KDE integration is presented in the report [8].

BENEFITS FOR KDE:
- KDE4 will be the first chemistry aware desktop environment
- example Strigi plugins for complex data mining
- powertesting the Strigi framework
- crossdesktop code reuse (benefits for other, e.g. Gnome, communities)
- speedup expected after porting analyzers to jstreams
- step towards the Semantic Desktop

For references and up-to-date proposal visit http://neksa.net/dokuwiki/doku.php?id=strigi_chem_bio_support

I intend to give support for GPS devices within the Marble application, implementing a method of recording GPS data and loading saved information into the user interface keeping the interface as simple and user friendly as possible. I will also implement tracking of a GPS object that is in the meta layer. A secondary goal will be a basic implementation of support for open street map.

At the heart of Amarok, the music player for KDE, is the playlist. Currently the Playlist class performs many functions. My proposal is give the playlist the tender love it truly deserves, by first making the playlist more modular and then redesigning its layout to improve its usability. The playlist is the central feature of Amarok, it needs to look good.

More details at:
http://amarok.kde.org/wiki/Playlist_Redesign

Windows Live Messenger 8.1 is widely used around the world, The protocol is MSNP15.
In last year's Soc MaYuan has supported the MSNP13 protocol for Gaim. The Kopete has done some work on implementing the MSNP13 in KDE4 trunks, but It's not functional,
Based on messenger plugin, this project will implement a functional and stable messenger plugin for Kopete and update its protocol to MSNP15, introduce some new features such as Offline Message,Communicate with Yahoo Messenger, Roaming Contents...

The goal of the Step is to make studying physics easier, more interesting and productive. It helps users to gain intuitive understanding of how physics works by allowing them to easily construct various experiments, interactively simulate them to see how they will evolve, adjust various physical properties to see what will change.

The underlying simulation engine of Step is available as separate library called StepCore and can be used for other projects which requires simulation functionality.

Step is a KDE4 application, KDE libs have already made development of Step quite faster and more enjoyable. When Step will be ready it can perfectly complement the kdeedu module and extend the realm of kdeedu to the whole new subject.

I've been already developing Step for two months. With help of kdeedu people, Step has its own section on edu.kde.org: http://edu.kde.org/step/ . You can look at it to learn more about Step, its current state and future plans.

Currently Step still needs more features, polishing and (especially) GUI improvements to become actually useful for education and to be included in kdeedu module. As part of the Summer of Code I propose adding some of this features and improvements to Step in order to make it more useful and ready to become a part of the kdeedu.

Xinerama (and various implementations known also as e.g. MergedFB or TwinView) is an X server extension that merges two or more physical monitors into one large display. KDE already provides a decent support for Xinerama, but there is still room for improvement, in particular, different monitors are linked together even in cases when it might be more beneficial to have them independent, for example with virtual desktops.

I plan on improving support in this case, and general Xinerama issues under KDE, especially regarding multi-monitor full-screen mode in media players.

This project aims to provide new plugins for the text engine of KOffice. The text plugins will mainly benefit KWord, but it is not limited only for KWord since the design of flake library allows component (shape) embedding in every KOffice application.Some of the text tools that are going to be implemented are:
* Bookmarks plugin
* Uppercase Text (change text to all lowercase, title cased, or capitalized)
* Text replacement: Use thesaurus to do text replacement for similar words, another example is text replacement by texting language.
* Colorization plugin
* An optional plugin that shows a word count in a docker

Marble is generic map widget to display geographical data. Currently is supports basic KML objects and acts as a basic Qt application. To become more useful and part of KDE EDU in my view it should has enhanced KML support and act as KDE component (kpart). My aim is implement redesigned support of KML objects and introduce more flexible architecture with realization of basic objects meet to KML 2.1 specification and to convert Marble widget to KDE component (kpart).

For a long time now kpilot is *the* application of the K Desktop Environment to sync your palm with the kontac framework. Syncing is done by so called conduits which sync handheld program data with the data of a desktop application. Most of the conduits are record-based, as in they check if records on the handheld are added/deleted/changed and update the application data and vice versa.
For now each conduit did the handling of records on its own way which makes bug-solving and maintenance in general a time consuming job. Because of this, and because whe decided to port kpilot to kde4 i'll implement a more generic way of record handling which can be used by each which is record based.

I'll deliver the following products at the end of the project:

* Sequencediagrams/classdiagrams
* Implementation of the abstract record framework
* (Re)implementation of a (new) conduit as proof of concept.

With this project the conduits of kpilot which make use of this will become more maintainable. It will become easier to create new record-based conduits and i'll be able to help a hand on the porting to KDE4.

Today, most people (at developed countries) carries some Bluetooth capable cell phone or, looking at the current supply at shops, they will very soon. Bluetooth is a wonderful technology that joins power efficiency with easiness, making things like file sharing, wireless hands free and so a child's game. Of course, Bluetooth is not an exclusive property of the handheld world, and it's easy to find USB Bluetooth devices in the 15€/10$ range, and many new computers include it by default.

In addition, Bluetooth management has been developed in the Linux world for some years, now we have the BlueZ stack integrated in 2.4 and 2.6 kernels providing a library to manipulate Bluetooth devices and a D-Bus interface with the same purpose. Also, KDE has gone it's way and has the KDEBluetooth project, which provides a DCOP interface to the underlying BlueZ DBus interfaces, but has one little issue, is not KDE4 ready. The first part of this proposal is to solve that problem.

All this plots an scenario where a user arrival/leaving can be easily identified from Linux using few different ways. What if your computer pauses the music you are listening on Amarok, locks the screen and mutes the audio when you leave, and also unlock the screen, restart playing your music and opens your favorite mail program and a browser with your favorite tabs when you get back to range. This is a feature that has already been included in OSX through the Proximity application, or even on Linux with the command line tool bluemon, so this proposal includes creating a similar application called Bluetooth Presence Manager, BtPM, using KDE4, on top of the previous Bluetooth support works.

KDevelop is an IDE that supports a wide range of Languages. Considering the fact Python is gaining widespread popularity as a programming language, the idea of my project is to bring decent Python support to KDevelop4.

At present time, the python support for KDevelop4 is in its infancy. The Language parser does exist for python but is not complete, it is quite basic and does not comply with python indentation rules. So developing a lexer that supports indentation (or porting existing lexer from ANTLR python parser) would be the first task.
The next one would be to make python parser understand a subset of the language.
Apart from that I plan implementing a Definition Use chain for Classes and methods and "Smart Highlighting".

The Entire Project will have three milestones:
- The Parser that is capable of reading predefined subset of python
- Definition Use chain for classes/scopes/methods
- "Smart Highlighting"

The Language parser that exist for Python is just in its early stages and does support much of the functionality, so Considerable amount of work needs be done to add complete Python support to it.

Today KOrganizer's theming interface, CalendarDecoration, is not widely used. Plugins using the interface have to be written in C++, and the functionality remains simple.
My goals during Summer of Code would be:
- to allow for more features (background images, image/quote of the week/month, etc),
- to write some example plugins (national calendars, "This day in history" links, ...),
- to make it easier to write simple decorations for KOrganizer using a portable and easy-to-use format, which may be extended in the future (like the KDE themes).

In this project I will add music notation support to KOffice. This will be accomplished by writing a new flake shape, which will make it possible to use this new feature in all KOffice applications. The goals of my project will consist roughly of 3 parts:
* a way to show and print music in all koffice apps.
* a way to edit this music notation
* a way to load/save this in ODF files, either using a KOffice-specific file-format, or the 'standard' MusicXML format.

Personal:
My name is Gavin Beatty. I'm 21 years old. I'm nearly finished 3rd year of my degree in Mathematics in Trinity College Dublin and I have been using Linux since Windows Millennium Edition ;) I have been a KDE user in all those years.

My studies have included C++, computer networks, isometrized 3D graphing applications in C++ and game development (last two using SDL).

My personal experience in this realm include coding QT 4.x applications for library management (search,status,reminders) and personal itches such as for easy ssh port forwarding (became quicker than monthly `man ssh`ing).

I have professional experience working with one of the largest (and Scandinavian ;)) telecoms companies in the world. There, I wrote testing frameworks in Python, debugged in Java and used many devel tools such as Subversion, ClearCase and all the major IDEs.

I teach C and UNIX to Junior Freshmans in the School of Maths in Trinity.

My passions are for Python, C++, QT and open source.

Kross is a scripting framework that allows a program to easily integrate support for multiple scripting languages. Currently Python, Ruby and KJS are supported.

This project aims to integrate Java as another supported scripting language. Java is among the most used programming languages according to various sources[1], so supporting Java in Kross opens a lot of potential for programs using Kross as a scripting backend. This affects among others popular applications as KOffice, KWord, Krita and SuperKaramba.

[1] for example "Programming Language Usage Graph" by François Labelle, http://www.cs.berkeley.edu/~flab/languages.html

The X Resize, Rotate and Reflect (called RandR) is an extension that provides a way for applications to resize and rotate the root window of the display. In addition to that, the latest release of the extension (1.2.1) provides some additional features that are not yet supported by toolkits and desktop environments. One of the new features is the ability to deal with monitor hotplugging and zero or more outputs displaying arbitrary regions of the root window.
From the desktop environment point of view, it is necessary to have an application monitoring for screen change events and managing all the available outputs and CRT controllers.

KDE already has an application that can handle RandR events and that can do requests when necessary. This application is called krandr. But currently it only handles RandR 1.1 requests, which is not bad at all, but being able to interact using RandR 1.2.1 brings many new possibilities for the KDE environment.

The idea of this project is to add necessary infrastructure for RandR 1.2.x support in KDE and make the desktop environment react and interact well with RandR requests.

To improve startup times of KDE applications, I plan to create an icon cache which would store all icons in a common location. This would eliminate the need to scan tens of directories for icon locations, thus reducing disk seeking. And as the cache would consist of only two files, it would often be wholly cached in the memory by the operating system, eliminating disk access completely.
Furthermore, the cache enables loading icons directly from SVGs, using any scale, as the SVGs need to be converted into pixmaps only on the first use.
Finally, the cache would make it possible to support simple icon compositing, making it much easier for third-party applications to provide icons which always fit into user's current icon theme.

This project is to develop a data import module for Sahana Disaster Management System. This module will enable the Sahana users to import data stored in different formats like CSV , XLS, ODS and XML in to the Sahana system. Also it would enable the Sahana system to produce reports in those formats. This module will be relay help full for new Sahana users to adopt Sahana in to there disaster management activities, and also enable Sahana to work with other data management applications.

Abstract
--------

In disaster situations, the most common method of collecting information from the victims is by filling paper based forms. To use that information in a disaster management system like Sahana, they have to be typed in to the system, which is highly inefficient and delays the response time in a disastrous situation.


The intension of this project is to provide an optical character recognizing tool which can recognize hand written English characters and save the data to Sahana database. The scope of the project will be limited to identifying English letters, numerical characters and other commonly used characters.


Implementing the OCR tool in the server side is not a good option as optical character recognition is a highly processor centric task, and will overload the servers and waste the network bandwidth while uploading the images to the server. So it should be implemented as a stand-alone application that runs on the client side.


The input to the tool is an image of the paper form, scanned from a normal desktop scanner.


Since the OCR is to recognize hand written characters, AI techniques in the form of Neural Networks should be used. Neural networks are vastly used in OCR applications, since once trained well, they give results with high accuracy even in cases where high noise is present in the image.


The characters in the input image have to be segmented and re-sampled before feeding it as the input to the neural network. The image processing part should also be efficiently handled.


To minimize the errors in the final output, the paper form has to be designed to make it easier to segment the characters and thus minimize the errors in the input.


The project is intended to be developed using C and C++, on Linux platform. Porting to MS Windows is also considered.

Extend and Improve the latest KBFX 0.4.9.x branch of the menu. I hope to make KBFX even more user friendly, by flat indexed menu which can be ported to run on the upcoming major release of KDE, KDE 4.0.

   “A Desktop resource launcher” hearing that may draw an image of a regular menu in your mind, which will load all the entries it has; such as all applications installed, administrative tasks, accessories, utilities etc... It is true that you may not interest in this image, because regular menu is sort of a mess and it is time consuming, since it has all the items and we have to find out what we need. So it takes time according to the loading speed and the time taken for searching relevant items.

   Think about a menu or in other words a Desktop resource launcher which shows only things or tasks that we should do, as its' entries.. And a menu which can be customized without editing the core part..!
The extended KBFX menu will be full filling this need using Task Oriented Menu (TOM) concept.

   TOM can load only some selected entries as 'things to-do'. These entries will be defined in an XML file and the XML can be loaded to the menu via a tom-plug-in. There can be a baseXML for Office and Internet tasks, mulitimeadiaXML for Graphics and Multimedia, an XML for Games and also another XML for Administrative tasks. Users can modify their TOM by loading these XMLs via a tom-plug-in or even loading their own XMLs. This will allow multiple users to have different menus with their specific 'things to-do' list, in a single computer.

   My main goal is to give life to this TOM in this summer, with lot of additional features like better keyboard support. And it will be eye candy.

Introduction
Global Positioning System (GPS) is a satellite system that provides highly accurate location with the use of special GPS receivers and their augmentations. This accurate GPS data is of limited use by itself, unless it is coupled with a powerful visualization tool like the Geographic Information Systems (GIS). The GIS is a widely accepted visualization tool that presents data in a graphic form, which is a convenient and effective means of communicating complex information. These systems also have loads of relevant spatial and non-spatial data existing as different layers of information that can be expressed as a map. Thus, the integration of GPS and GIS brings into existence a powerful tool that has location and visualization aspects that can be put to effective use in the context of a disaster . The aim of this project is to develop a platform independent GPS interface to the Sahana disaster management system,which ultimately produces a strong integration of GPS and the existing GIS features of the Sahana system. This GPS/GIS integration would enable Sahana to communicate with GPS receivers very easily and efficiently allocate resources, model risks, and direct emergency response,relief,rescue,rehabilitation and recovery personnel.

Deliverables of the Sahana platform independent GPS interface

1>Administrative interface to GPS devices -specifies the type and model of the GPS device,synchronizes the datums of maps and GPS device's,specifies ports,baud rate,etc
2>Format conversion interface -converting way points such as in Universal Transverse Mercator (UTM) to latitude and longitude and vice versa and many more format conversions.
3>The Import/Edit from GPS interface -imports waypoint/routes/tracks from the GPS device to the SAHANA system and provides the option to edit them.
4>The Export to GPS interface -exports waypoint/routes/tracks from the SAHANA system to the connected GPS device
5>The GPS map export interface -converts maps to GPS device compatible formats and exports those maps to GPS device.

Tools
Java is to be used to as the programming language for this project as it achieves platform independence and NMEA compatible GPS receivers are assumed to be used in connection with the SAHANA client as NMEA is the standard GPS device protocol. USB/Serial, bluetooth/Serial converters(software) are to be used to connect GPS devices through bluetooth and USB to the Sahana client. Java communications API 2.0/3.0 and jUSB are to be used to access ports.

This project would be an attempt to provide AJAX (Asynchronous JavaScript and XML) support for Sahana. The current implementation of Sahana deals with AJAX little bit. AJAX can use to create better, faster, and more user-friendly web applications. There are lots of areas (modules) in Sahana that AJAX can be applied effectively. Therefore this project is important for Sahana to be able to perform efficiently and more user friendly way.

I see this product as similar to pivot tables in Excel or as more advanced, like reports in one of Business Intelligence tools (Crystal Reports, Business Objects, Pentaho). Request is to allow use it via web interface. Hence my idea is to apply R statistical system (http://www.r-project.org) which can be integrated with virtually any other language (e.g. with Java via RServe). I would like to communicate with R from PHP level using R-php (http://dssm.unipa.it/R-php/). R will deal as computational engine. As platform for interface can deal Rpad (http://www.rpad.org/Rpad/) too. A simple example of dynamic report generator can be found at http://www.rpad.org/Rpad/DataExplorer.Rpad.

Pivot tables supported with drag and drop technique will be applied (thanks to Rpad). Huge graphical data presentation possibilities of R statistical system will be applied. We can think of generation of pdf reports too.

R can access almost any database. MySQL databases can be reached via RMySQL interface library.

Of course, we do not have to use R and we can support pivot tables and dynamic reports with direct use of database queries from PHP level. We can apply mixed approach too: simple queries directly using SQL queries, more computationally complex (or statistically advanced) using R system.

Sahana allows tight GIS integration (Google Maps), hence it could be applied to some very simple geographical visualizations. More advanced generation of maps could be needed, e.g. in case when we would like to visualize population density with colors. Such other approach to generation of maps could be supported by R too (it has several packages allowing this) but for greater flexibility GRASS GIS software (http://grass.itc.it/) could be used. It can be accessed via GRASS package for R. I am not sure if application of such advanced GIS system in Sahana is necessary / needed / possible. It should be investigated while beginning part of the project.

The solution with use of R system will allow us to easily expand analytical possibilities when advanced needs will appear. I think that is really worth considering.

I suggest to exclude geographical visualizations and pdf reports from scope of the project. Application of several tools may consume too much time and technical difficulties can cause project failure.

Once a disaster occurs anybody should be able to download the opensource software and adapt it to their geographical location as quickly as possible.So adaption of the language to the geographical location definitely ease the disaster management process by enabling volunteers to use the sytem from their mother tongue and acclearate the data capturing process.

When disaster happens lot of volunteers are speaking and understand there mother tongue. If we can make effective localization for Sahana which take to translate the site less than one day that would be very much helpful.

Localization should be user friendly because translation are done by translators who are non technical person, to translate site if we required translator and technical volunteers that would be a problem.

We can make localization module like this when user switch to Sahana localization mode they able to translate words while they are looking at the Sahana site. For instance if user want to translate 'Sahana Disaster Management System' into there language they can highlight that word phrase and press enter then they get text box saying please type translate word. After translation done when they say apply for particular module then we are creating *.mo file internally.

Bassa is a new project, that aims to build a policy based content caching, distribution and sharing
system that is fully transparent from the web users' perspective.
The ultimate goal of the project is to build a system that will efficiently utilize the available
bandwidth in a timely manner using Quality of Service (QoS) and efficient bandwidth throttling.
As an added benefit, the system will also be extended to provide a rich web 2.0 interface called
GADisk, that enables anyone to share their downloaded content such as
multimedia/documents/entertainment.
Therefore Bassa can be considered as a next generation proxy server extension that is capable of
enhancing an existing proxy server to efficiently schedule and download content. It is primarily
implemented using the C language for better portability and efficiency.

In a disaster the whole community work together and try to mitigate the effect of the disaster situation.Huge amount of funds flows in and some times the amount may be more than required.If they are not properly managed it may lead to another disaster.Funds should be managed very carefully and requires high degree of professional skill.it is very costly and time consuming task.In a disaster, time and money will be the most scarese resource.

  As a solution to the above problem the Fund Management module will automate the fund management process.This will manage fund distribution process centrally and allocate correct and appropriate funds to correct places at the correct time.furthermore this will include an accounting statement generation submodule and several financial and non financial reports.

Package Manager Module:
-----------------------------------------------

There are number of modules available in SAHANA. If we take a user he will not need all the modules. There are so many functionalities are included in to the whole system and those functionalities are embedded in to the different modules. For example if any user wants to make a request, the request management module will be the expected one. In this case it will be convenient to user if he allow to manage the system by selecting only the appropriate modules they want.

A good system would have to address the needs of usability, customizable and the accessibility since it improves the ability of make the task easy. Package Manager Module is the best selection to achieve those goals without affecting current usability of the existing system.

By addressing the Package Manager module user will be able to select only the appropriate modules and select the themes according to their preference.

IOLib¹ is an effort to create a library for Common Lisp applications
doing high-performance network I/O whose ultimate goal is to provide
a framework for doing event-driven multi-protocol network
programming not unlike the Twisted² and POE³ libraries for Python
and Perl, respectively.

  With this goal in mind, this project proposal includes work on a C
groveler targeting CFFI, a POSIX layer, a Win32 layer, a
multi-platform sockets API, an event notification API and an I/O
multiplexer.

¹ <http://common-lisp.net/project/iolib/>
² <http://twistedmatrix.com/>
³ <http://poe.perl.org>

CL-ObjC is a portable Common Lisp / Objective C bridge, whose ultimate
goal is to be able to build Cocoa applications on Mac Os X by using
Interface Builder to design the GUI and then implement any required
code entirely in Common Lisp.

At this time the CL-ObjC project state is very experimental though the
source code already written demonstrates his ambitious final goal can
be easily achieved.

Common Lisp is an high level programming language supporting a
combination of imperative, functional and object oriented programming
paradigms, compiled code, dynamical safe and strong typing, and
extensible with macros.

Several libraries and tools available for Common Lisp are often
conceived to be used from the REPL (the command-line traditional
interface). As a matter of fact this way of use, though powerful for
an experienced lisp user, put little barriers up for newcomers.

Having a tool to easily build modern, well-integrated with the OS and
beautiful graphical user interfaces, will help lower the impedance to
entry for new Common Lisp developers, and so will be helpful in
advertising the whole Common Lisp community.

CL-ObjC is a Common Lisp library that aims to help users writing GUI
for their domain-specific applications, using all the features of the
Cocoa framework, and all the power of an industrial strength lisp
language, like interactive development through REPL.

Actually CL-ObjC aims to provide the following features:

* access to the Cocoa Objective-C based APIs using CFFI to guarantee
  portability among Common Lisp implementations;

* Documentation, simple examples (Hello World, widgets demo), and a
  demo of a Common Lisp library (e.g. cl-skippy).

* close integration with the Interface Builder;

* multithreaded execution in order to recompile and eval lisp code typed
  at the repl;

* CLOS (Common Lisp Object System) and macros interface for low level
  features of the Cocoa Framework, in order to provide a more
  functional and Object Oriented interface to them.

At this time, a accurate TODO list is available for the project,
including the steps to implement the former features in the order.

My project proposal concerns in the initial stage the completion of
the first two features, including the refactoring of the existing
code. Then we will add examples and documentation to consolidate the
work. In the last phase, depending on how much time is available we'd
choose between the last two features.

Functionality will be added to the Gsharp score editor allowing the importing and exporting of MusicXML files. With support for this interchange format, users of Gsharp will be able to integrate it into a work environment that includes a bevy of other music software.

The aim of this project is to write a Common Lisp library for the Mindstorms NXT platform. It would provide a facility to write NXTLisp programs to run on NXTs, remotly and simultaneously control one or more NXT agents or set up a network of NXTs that communicate with each other.

Mindstorms NXT is a programmable robotics kit produced by Lego. It is commonly used by universities and hobbyists around the world. The base kit is extensible by various sensors and components thus making it a perfect platform for learning and experimenting in various IT-related fields like AI, robotics or multiagent environments.

Mips is a RISC processor architecture known for it's simplicity.
LLVM compiler infrastructure currently does not generate machine
code for Mips architecture machines. The project goal is to
implement the Mips backend support on LLVM and enable Mips machine
code generation.

The goal of this project is to modify the QEMU dynamic binary translator to use components of the LLVM compiler infrastructure to turn it into a highly optimizing dynamic binary translator in order to increase the performance of QEMU even further. Instead of directly emitting code for the host architecture QEMU is running on, the target code is first translated to LLVM IR, then a selection of LLVM's optimization functions are applied to the IR and the LLVM JIT is used to generate code from the optimized IR for the host architecture. Since the translation to LLVM IR, the optimization and the code generation comes at a cost of an increased execution time, it's not feasible to apply this process to any piece of code, else the execution time would be even lower. Especially since on average a program spends 90% of its time within 10% of the code it is critical to get these 10% to execute fast, for the other 90% of the code parts might only execute once or only a few times and the extra time spent to generate the optimized code would not pay off. Therefore the idea is to identify the "hotspots" of the program. The most simple way is to count how many times a piece of code has been executed and performing an optimizing translation once a certain threshold is hit or falling back to the current binary translation of QEMU if not. Another approach could be to instrument the target code at LLVM IR level to get an execution profile (LLVM already contains support for profiling) and use it to identify hotspots and to be able to perform profile-guided optimizations during runtime. Possibly a combination of both approaches will lead to the biggest overall performance gain. Detailed speed measurements will be performed in order to evaluate the efficiency of the different approaches, especially in comparison to the approach currently used by QEMU.

The MassSpecWavelet package in the Bioconductor provides a novel way of performing highly accurate peak detection on Mass Spectrometry data. The package utilizes Continuous Wavelet Transforms to find peaks in the data at various resolutions.

The CWT filtering used can be performed on any 2-dimensional dataset, however extensions need to be made to the package to allow it to read in a wider variety of data formats. In particular, the authors would like to be able to support LC-MS/MS data, mzData and NMR metabolomics data.

Other modifications also need to be made to the existing data structures so that the provided functionality can more readily be shared with other packages in the Bioconductor.

In addition to these extensions, the authors would like to see a suite of standard signal processing tools to give users the ability to filter and analyze the data in multiple ways. Another idea along these lines would be to provide a matched filtering algorithm to allow users to compare unknown datasets with known ones.

A common source of metabolomics data is chromatography mass spectrometry. Adding support for this type of data to the MassSpecWavelet package will require adapting and expanding the package to consider the chromatographic time dimension.
A separate peak detection algorithm may be required for chromatographic peaks, since their shape differs from that of mass spectral peaks. Chromatographic peaks often overlap, necessitating a deconvolution procedure. Also, the large degree of temporal shift between samples requires aligning them by retention time.
The identification of metabolites is especially challenging in
gas chromatography, where each metabolite is fragmented into multiple ions. The individual ions must be grouped together for identification. The new version of MassSpecWavelet must address all of these issues. To avoid reinventing the wheel, the package should be integrated with existing software for metabolomics, such as the xcms Bioconductor package, where appropriate.

It would also be beneficial to make the MassSpecWavelet package generally more adaptable and more accessible to biologists. This would involve improvements along three axes. First, the design should be based on a modular, extensible data analysis pipeline. This would enable expert users to adapt MassSpecWavelet for specific needs. Second, MassSpecWavelet should visualize results and algorithm diagnostics with interactive graphics that promote open-ended
exploration of the data. Every dataset is unique and requires a flexible means of visualization in order to detect problems and to discover the unexpected. Finally, a graphical user interface (GUI) should be provided so that biologists are able to use MassSpecWavelet without spending valuable research time climbing steep technical learning curves.

Adding metabolomics support to MassSpecWavelet is the priority for this project. General improvements will only receive attention when they directly support the metabolomics efforts.

SYNOPSIS

G3L or Google Gateway to Genomics Literature is a website, which provides access to recent scientific data and research articles in a visual manner, that focuses on a clear representation of what is new and what is popular among the users - all without scrolling.

BENEFIT & PROJECT DETAILS

Inspired by Newsmap (http://www.marumushi.com/apps/newsmap/newsmap.cfm), G3L immediately attracts attention by its visual appearance. Items on the website are arranged over the whole screen, taking advantage of current high-resolution or widescreen displays, while assuring readability and a clear design. Depending on the popularity among the readers and on its age, items are be highlighted, e.g. by increasing the font size of the heading or applying different colours.

The data for the website is collected by spiders, that retrieve and parse web content from various relevant internet sources. The different sources are used to provide the grouping for the articles.

The website is developed using the Ruby on Rails (RoR) framework and a MySQL database. This allows for an open and modular style of programming, while using AJAX techniques to provide an easy and attractive user experience. This is, in particular, used to load details for a particular item on the screen upon request by the user.

- Goals and Project Interest for 2007 SoC
 
 I am primarily interested in the GenQuad project. The goal of this project is to summarize the function of each gene using four keywords. The source of information to find which words will be used is mainly "geneRif" (ftp://ftp.ncbi.nih.gov/gene/GeneRIF/generifs_basic.gz). Since this file records almost 500,000 descriptions, some approaches will need to be tested.
 A good approach is to use the Word Level method, so that word properties, stop-words, stemming, frequent N-Grams and Thesaurus techniques may be applied. The weight of each one of them will need to be measured, and a gold-standard will need to be defined. Since professionals from the field are the ones who can better evaluate what is a good summary for the genes, some feedback from them might be needed.
 One technique that will receive more focus is the "Frequent N-Gram" one. Since it has an easy dynamic programming algorithm, and yields to good results in other areas, this technique will be deeply explored. Another apprroach would be using "Approximate N-Gram Markov Model"
(http://nlg3.csie.ntu.edu.tw/conference_papers/qualic1994b.pdf), which describes an O(n) algorithm for such implementation. The quality of both algorithms must be evaluated.
 In the word level field, we also want to determine whether CAP algorithms are suitable. Implementing such algorithms and comparing to the gold-standard may prove it.
One paper used to get some previous experiences will be (http://www-nlpir.nist.gov/trec/pubs/trec12/papers/ntu.genomics.pdf)
Another interesting field would be exploring the Document Level. Topics such as Summarization, Single Document Visualization and Text Segmentation algorithms will be used to evaluate if techniques in this field are suitable for the task.
 During my research, I will examine open source text mining tools so that previous work may be added in short period. Main Text Mining tools studied will be GATE(http://gate.ac.uk/), WEKA (http://www.cs.waikato.ac.nz/ml/weka/), MALLET (http://mallet.cs.umass.edu/index.php/Main_Page) and LingPipe (http://www.alias-i.com/lingpipe/).
 Besides all the research work, I intend to provide the results in a web-enabled database, for easy query retrieval, using AJAX technology. Since I’ve had a lot of experience in a software factory, these approaches will be quite straightforward.

In order to allow for complex, non-standard, or configure-lacking ports to built universal binaries, often configuring and compiling for a single architecture is required, once for every requested architecture (2 for 32bit u.b., 4 for 32bit+64bit u.b.). After every such run, the output needs to be backed up to a temporary location. Once that is done, lipo needs to be run on all those files.

Openssl is the first port that allowed for building u.b. in such a way, everything from line 50 on deals with u.b..

  http://trac.macosforge.org/projects/macports/browser/trunk/dports/devel/openssl/Portfile

I'd like to automate and beautify such universal variants through functions, as described here:

  http://trac.macosforge.org/projects/macports/wiki/SummerOfCode#Task8:Portfiles

e.g. functions for lipo and backing up are needed.

I'm going to implement building port in isolated environment. I'll add to inject library ability to reject attempts to read file, so program will se only ports which was wrote in portfile.

Now inject library communicate with tcl code and can log read attempts. We need to add backward communication. So inject library should ask read-abiltiy for every file.

To reduce performance penalty we need to cache on library side.

A universal need of package managers such as MacPorts is the ability to track dependencies between packages and determine if one package needs to be installed to support another. There are, however, some important deficiencies in the MacPorts dependency resolver, and in fact, in package managers in general. I propose to address these issues in MacPorts by designing a new repository backend for tracking ports, and an appropriate suite of functions to query it.

This backend will be capable of tracking a wider range of requirements: in particular, it will let packages request particular variants and versions of other packages. This is important to the MacPorts project because it will improve the reliability of the dependency system.

Additionally, the dependency graph will be represented in such a way that it will be possible to identify stages of installation that can be performed simultaneously. This is important because, as processors tend towards parallelization, it will be necessary to split the process of installation into concurrent tasks.

Location-awareness would open various new possibilities for Maemo-based
devices. Examples of such possibilities include a camera application that
automatically tags pictures with a 'taken at' address or an automatic timezone
setting. At the moment adding location-awareness to applications is so
difficult that only specialized applications, like gps-map software, do
anything at all based on the users location.

The goal of this project is to provide Maemo application developers with a
easy to use API for basic location-services, like acquiring current coordinate
position or street address. To reach this goal I plan to package the GeoClue
library for Maemo and to develop the necessary user interface to make GeoClue
functional from the end-user perspective.

Links:
http://geoclue.garage.maemo.org/ -- Project home
http://vilunki.wordpress.com/ -- project blog
http://maemo.org/ -- Maemo home
http://geoclue.freedesktop.org/ -- Geoclue home

A project was recently added on "garage" [1] to add the CJK (Chinese, Japanese, Korean) support on the Maemo platform. With about 1.5 billion people using CJK in the world, this allows the Maemo platform to target a much broader population.

However, a feature which is extremely common in the PDA with a touchscreen is still lacking: handwriting recognition. Handwriting recognition is useful when people want to input a character that they cannot read and thus cannot input with the standard input method. This of course often happens to foreigners learning CJK but also to native speakers when it comes to unusual characters. That is why handwriting recognition makes so much sense for Japanese/Chinese PDA. Other possible applications of handwriting recognition include dictionaries and character (kanji) learning games.

This Google Summer of Code project aims to add support for Japanese/Chinese handwriting recognition using tomoe. [2] Focus will be on performances and smooth integration with the current input system and latin character recognition.

[1] https://garage.maemo.org/
[2] http://tomoe.sourceforge.jp

The purpose of this project is to implement the simplified NGS scheme specified at:

http://wiki.musicbrainz.org/LukasLalinsky/NGS

The goal is to reach at least step 5 on that roadmap.

The purpose of this project is to analyze and improve upon the beat detection algorithm implemented in mixxx. The project will begin by analyzing Mixxx's implementation of the "Real-time beat estimation using feature extraction" method for areas where the current code could be improved. Then, research will be conducted to determine what other methods/libraries are available for real time beat estimation. Using the results, either the current implementation will be improved upon or at new method will be implemented.

LADSPA [1] is an acronym for Linux Audio Developers Simple Plugin API. It is a standard for audio processing plugins, mainly filters and effects. Currently, many free software projects benefit from using these plugins, which let the users apply both simple and advanced effects to their audio signals without forcing developers to spend time implementing filters which already exist. The spare time can then be assigned for implementing other features, perhaps more innovative. Despite the name beginning with "Linux", so far LADSPA is the most cross-platform widely adopted solution for audio plugins.
At present, Mixxx is offering only a built-in flanger effect. Therefore the goal of my project is to implement support for LADSPA plugins within Mixxx.

[1] http://www.ladspa.org

Nowdays, wikis are widely used as tools for fast and efficient sharing
of knowledge, that in contrary to other forms of Internet communication (like IRC or IM networks) offer persistence and encourage collaboration by providing full access to the information. Various means of control are used to keep the content from being corrupted either by malicious users or plain mistakes. These include full logging, tracking of changes and author/admin notification systems. A common use pattern also includes using 'talk pages' to discuss changes being made to the content.

I find email notification systems slow and not interactive, and as a natural consequence of this, I believe that developing means of interactive, Jabber/XMPP-based content handling might greatly improve the usability of the MoinMoin project. This would include: Jabber/XMPP notification of subscribed users (useful to fight spam or keep track of changes made to heavy-traffic pages), simple editing options like adding a comment at the end of the pages (again, tremendously useful for talk pages as all the user has to do, is write a reply in the IM client) and efficient anti-spam fighting measures (an option to revert a particular change with one command). This functionality should be implemented in a separate daemon, to reduce latency and overhead of networking operations.

Progress is being tracked here: http://jabba.pl/grzywacz

Project Description

 The Classification Feature will provide MoinMoin the ability to automatically group related wiki pages based on user feedback and to implement new actions (notification) when new content is added. The project should implement state-of-art algorithms like: Bayesian classification, Support Vector Machines or Artificial Neural Networks.
 The other features that I am interested would help to provide a more secure and usable MoinMoin.

Project Motivation

 Currently, MoinMoin does not provide a way to classify wiki pages based on their content and these feature would allow big MoinMoin installations to provide supervised or unsupervised text classification.

=== Introduction ===

Hi! Firstly a bit about myself. I am a second year BSc. Software Engineering student in the University of Hull, UK. I've been interested in .Net since I got my .Net 1.0 Beta 1 CD and I've been following the Mono project for almost 2 years now. Event though Mono has quite a decent Windows.Forms support, being actively worked on, as a Mono and also a GNU/Linux user and developer I am not able to design Windows.Forms interfaces, nor edit alreadyexisting ones in a visual and pleasant way. I've been researching on the topic since summer 2006.

=== Summary ===

This project is targeting at:

1) Providing an implementation of the .Net 1.1 and .Net 2.0 Design-Time stack for the Mono Class Library, mostly hosted in the System.Design assembly and .Design/.Design.Serialization namespaces. The stack consists of:

    * A DesignSurface (Host)
    * Windows Forms Designers
    * ASP.NET Designers - not targeted by this project.
    * Serializers

It should be noted that SharpDevelop relies on this stack.

2) Integration in MonoDevelop to enable:
 
    * Designing Windows.Forms interfaces
    * Full forward and backward compitability with Visual Studio generated interfaces.

=== Status and TODOs ===

The project is hosted at http://monodt.i-nz.net and managed via Trac and Subversion. It currently provides an initial .Net 2.0 ready implementation of the DesignSurface and .Net 1.1 ready core Windows.Forms designer stack, which allow dragging and droping, selecting and resizing controls. Initially development was done on Windows and MS.Net, but after 2 bugfixing cycles, which introduced about 15 bugfixes and patches in the Mono Class Library related to Design-Time behaviour the code works fine on Mono and the development has moved to Linux/Mono.

TODOs are:

    * Improve selection, drag and drop and resizing behaviour and design
    * Implement the Serializers
    * Merge with Mono's class library
    * Implement the specific Windows.Forms designers per Control basis.
    * Update core designer stack to .Net 2.0
    * MonoDevelop integration
    * Extensive testing

Very few web servers are supported by mod-mono-server, namely, XSP and Apache. More servers support FastCGI, either internally or through a module, including Apache, Microsoft IIS, Netscape, SunOne, and others. As such, a FastCGI mono server could improve mod-mono-server's market share.

The primary target is:
1. A FastCGI bridge to XSP, similar to mod-mono-server.
2. A configuration page (aspx) and a web service to adjust or reset the server's configuration remotely.
3. Create sample configurations for common server setups, prioritizing based on market shares.

Secondary targets (as time permits) would be:
1. Creating a test program which determines the optimal FastCGI settings for a given computer.
2. Configuration software which uses the configuration web services, console, Gtk#, and/or Windows.Forms
3. Implement a FastCGI 1.0 authorizor, so that HTTP Authorization could be handled through through mono.

The Mono Project is one of the fastest moving open source projects, this a very good
thing but the work done in the area of Documentation is lacking and the amount of documentation
to be reviewed or created is huge. So to close this increasing gap an application that helps in the
creation and edition of documentation with a very low learning curve is not only good but a
necessity for the project.

So a WYSIWYG Editor will be integrated into the Monodoc application that will make it easy to edit the documentation, there will be an option in Monodoc to enter Edit Mode that will present to the user with 2 panels: one panel with a "Documentation Palette" (in style of the Dia palette of the widgets palette in Monodevelop) and another panel where the document will be shown. The user will drag elements from the palette and drop them in the document and the editor will restrict the drop of certain elements depending in the visual context of the area where the user is trying to drop the element.

This functionality will be abstracted so that it can be used for a plug-in for MonoDevelop, so that any ECMA documentation is associated to the editor.

The aim of this project is to make a substantial contribution to the Gendarme project, akin to Microsoft's FxCop or Java-based FindBugs, for performing static code analysis. Static code analysis means inspecting code without running it - in case of ECMA CIL resulting in inspection of the code after it has been compiled to intermediate language. Static code analysis is a powerful tool for developers who strive for high quality of their code. Although it can not replace human code reviews, it is invaluable in pinpointing bad practices, finding omissions or common mistakes.

MonoDevelop currently has some tools to allow browsing of databases inside the IDE and an editor to write SQL queries. However, these features are currently very basic and could use some serious improvements.

During the summer, I would like to add the following features to MonoDevelop:
* SQL parsers to provide syntax checks and code completion
* Graphical database overview
* Graphical Database designer
* Database unit tests
* ...