SoC 2009

About me:
I am Arun SAG from india doing final year B.E. computer science and Engineering.I have been working with drupal for the past 2 months.I am looking for a chance to contributing to it.

Overview

Integrating a Image gallery in drupal.I found a javascript image gallery, and i would like to create a drupal module so that i could use it in drupal with ease.

Description

I would like to create a drupal module for this (http://www.puidokas.com/portfolio/frogjs/) image gallery script.

Features:

Many out of regional Websites use their own language, different from English, and they don’t need the opportunity to use several language versions of the website. I suggest importing the translation directly into the files of the source code, processing on the functions t() and inserting instead of English expressions, expressions of the required language.

Overview: Views have only used minimal amount of the power of taxonomy. Some of the rich feature of taxonomy were never explored. This is a project to implement some codes to make views do more with taxonomy.

Description:
Currently, the only thing we can query about taxonomy in views are.

• Is one of a set of terms
• Is non of a set of terms
• Is all of a set of terms

There is no support of term relations at all.
If a node N is associated with term A and B, where B is a child of A, then the user might only tag the node with B. With the current views, a user specifies to select nodes associated with A, N will not show up. Thus is one of all children/ direct children comes in handy.

With this idea in mind, I believe here are some features might be awesome for views to have

• (Is one of/Is non of/Is all of) + A term + (all parents /direct parents /all children /direct children /related)
• (Is one of/Is non of/Is all of) + few terms + (Union/Intersection of)+(all parents /direct parents /all children /direct children /related)
• When those are not enough, more complex taxonomy queries can be made in views. Only a query language based on term/term will be implemented. (i ('triangle' 'ellipse') (! (p 'circle'))) means return terms 'triangle', 'ellipse' that is not a parent of 'circle'. The returned terms can then be used to find nodes, perhaps though tql, which is a query language based on term/node relation.

The all parents and direct parents functions can be replace by a nth level parents function, gives it more functionality.

Here is a description of the query system and what will be achieved.

The query system can take the full power of the taxonomy system and return all the terms(not nodes, but could be extended to nodes) meet the specific requirement.  The syntax is lisp like, but different keywords.

There will be 3 stages in the query system. One must be completed in order to work on the other. User can chose which stage to activate in module administration.

STAGE 1. Relational select.

This stage only supports queries based on taxonomy relations. The result of a query is a list of term(s).

During stage 1,There are only 2 types of manipulate-able data. list(of terms), terms(or negative terms).

Here are some functions.

Basic structure

• 'term name' returns 1 or a list of terms with "term name" as it's name
• ('foo' 'bar') is a list, list a can contain terms or more lists. Each element is separated by space
• 1 this is a integer, in stage 1, it is the same as return a term with id 1.

Selection functions

These functions are kept to be minimal in size, because these are the ones most likely to be used.

• term return the term.
• (c term) returns all direct level children.
• (c list) (c term term term) is the same as ((c term) (c term) (c term))
• (p term) returns all direct level parents.
• (p list) (p term term term) is the same as ((p term) (p term) (p term))
• (r term) returns all related terms.
• (r list) (r term term term) is the same as ((r term) (r term) (r term))
• (| list) (u list) union lists of terms, also works as 'or' in conditions
• (& list) (i list) find the intersection of lists of terms. , also works as 'and' in conditions
• (! list) (n list) turn every term in the list to it's negative counter part. For a term, it return negative term. For a non-zero integer, it returns integer * -1. For 0, it returns 1. so it can be used as not in conditionals.
• (lca list) Lowest common ancestor of all terms in the list. This is a example of higher level functions in stage 1, more will be implemented, for efficiency reasons.

This set of functions is enough to select any possible set of terms though term relations. Efficiency is the main concentration.

For any function in stage 1, it's ok to have multiple list as inputs, it will flatten and join all the lists. u( p('foo' 'bar') 'bar2') is the same as u( (p('foo' 'bar') 'bar2'))

Stage 2. Conditionals and loops

Stage 1 should be good enough for most people, considering entering stage 2 will make the query language enough to do programs.

Conditionals and loops

• (> int int) first integer larger than 2nd integer, return 1, else 0
• (< int int) first integer smaller than 2nd integer, return 1, else 0
• (<= int int) first integer smaller than or equal to 2nd integer, return 1, else 0
• (>= int int) first integer larger than or equal to 2nd integer, return 1, else 0
• (/= int int) (!= int int) first integer doesn't equal 2nd integer, return 1, else 0
• (if int list list) if 1st integer > 0, do the 1nd list, else do the 2nd list.
• for and while loops.

Stage 2 functions

• (is_child list list) return 1 if every term in list 1 is the child of every term in list 2, else return 0.
• (is_parent list list) (is_parent a b) is same as is_child(b a)
• (is_related list) return 1 only if each term is related to all other terms in the list.
• (is_sibling list) (is_sibling a) is the same as (if (> (size (i (p a))) 0) 1 0)

• (size list) return a list of number in the list.
• (rsize list) return the total number of terms in the list, it runs recursively.
• (+ list) (- list) (* list) (/ list) (% list) basic arithmetic functions.

A possible example of return all terms under "triangle" with more than 3 children.

It's possible all the condition and loops be replaced by a sugarcoat of SQL WHERE.

If it's the latter, everything in the conditionals and loops list will be replaced by (w string), where here string can be a SQL WHERE statement.

Stage 2 allow a new type, integer. There is no distinction between term and integer in representation.

STAGE 3

During stage 2, it will support more than queries involve on calculations of taxonomy relations. It will work on other taxonomy data, like name and description. It can also some useful function will be made into the system. Include a new type string, and possible uses for it. For example, return terms starts with letter "c" and is a child of "animals" will be possible. It could be merged with stage 2 if SQL WHERE statements are more efficient.

Why is the query language useful?
The query language is not useful for small, tree-based, not-well-structured taxonomy. But when there is any taxonomy having terms with multiple parents, the query language can show it's power.
If a person want a wine that is both "Loire" and "White Wine", he can select the children of the common children of "Loire" and "White Wine". In this case, it returns any node tagged with "White Loire". Suppose a user enjoys "White Loire" and "Semillon". He want to find any other wine to drink. It's reasonable to say there could be some common property of those 2 wines made the user like them. So the user can use the lowest common ancestor(LCA) function. LCA finds the nearest common parents for both terms, which can be considered as the common property of both terms. LCA of those 2 terms will return "White Wine", and the user then can browse other terms in "White Wine" and might find something he likes. The query can become complex. Users who don't like "Loire" but enjoy "White Wine" can return only terms that are children of "White Wine" but not "Loire", unless it's both "White Wine" and "Loire". That query can be written intuitively as (u (i (! (c 'Loire')) (c 'White Wine')) (i (c 'Loire' 'White Wine'))).

Rough timeline

Starting from the coding day:

1st week of coding: Complete all taxonomy query operations for views described in the proposal. This does not include the query language.

2nd week: start implementing stage 1 of the query language

1 week before mid-term: complete stage 1 and make sure stage 1 system works correctly.

just before mid-term: make the decision on how to implement stage 2 and 3.

after mid-term: implement stage 2 and 3.

1 week before August 10th: integrate the query language with views + work on documentation

August 10th to 17th: fix bugs, do some tests and set up a demo site.
Mentors:

• randommentor0 - Anyone interested to be my mentor?
• randommentor1 - backup mentor, will help with coding standards, etc.
• ALocalMentor - I will be in US only till middle of July, and I will be in China for the rest of the summer.

Difficulty: medium

My Google Summer of Code proposal
My name is Tamás Demeter and I study at University of Szeged. I have 5 years of PHP, HTML and CSS experience. I want to have fun in the "boring" summer (no school, less programming :( ).

I am working as a professional Drupal site builder since the end of August (I worked in the video crew at Drupalcon Szeged). I would gladly take more participation in the community than now (right now I only hack together themes, and 10-line-long tiny custom modules with Drupal). Sometimes I submit patches, but that is all what I have done for Drupal.

Overview:

Create a social networking (SN) framework in Drupal 6 (D6) that integrates existing contrib modules together and create modules to extend SN features currently implemented in contrib modules.

This proposal is based on justageek's community proposal.

Motivation:

Notifying users of new content, events, actions is something that is common to enterprise level applications, social network or simply a blog. Notification can happen in many forms and via many mediums, some of the prominent ones being e-mail, instant messaging, SMS or live feed. Solutions uptill now have been separate and distant to each other, even though the problem is essentially the same, that is some message needs to be relayed to one of your user. The medium and carrier would differ and so would be the urgency and priority of delivery.

This project got selected in GSoC 2009. The abstract will be updated soon to reflect our latest plans.
Overview:
Vote Up/Down is a popular and widely used module for most of Drupal's voting requirements. The module was originally written way back in 2006 by Fredrik Jonsson (frjo). It is now maintained by me (lut4rp). I also ported the module to Drupal 6. This proposal aims to make Vote Up/Down the rockstar of all voting modules by accomplishing some very important pending tasks and feature requests.

Hi all, my name's Jean-André Santoni. I live in France, I'm still a student and I am interested in Drupal :)

Here is my proposal for Drupal and GSOC 2009 :

Overview:
This project focuses on handling node conflicts. Currently when a user tries to save a node that has been edited (and saved) before they have submitted, an error appears and the edit is blocked. This module aims to resolve these issues automatically if possible. If not, it will provide tools and an interface to interactively merge the two different versions of the node.