SoC 2007

hi folks,

i envy those of you who are already actively working on their projects!
since i have some rather intensive tests at the end of june, i don't have much time to spend on gsoc yet. so i spent the last couple of weeks reading the ebatns api (which is an external php api for ebay) and to setup a nice simple working environment. nothing fancy, just a few simplistic shell scripts to clean up and reset everything to a clean status quo, in case i make mistakes .-)

have a nice day!
jakob

This project, like the rest of my life in general, is dedicated to my father, John Melançon, 1928–2007.

I'm a week [or two] behind on GSOC updates. I'll try to catch up with a couple in the next few days, and then be on report-back schedule every Friday. Less focused data dumps have been and will continue to be posted to Agaric Design Collective's site (desperately in need of an overhaul).

The Community Managed Taxonomy (CMT) vision, to recap, is the option to put taxonomy vocabularies under the control of your site's user community. Huge free tagging vocabularies can become consolidated and even hierarchical without giving up any of the openness of community tags. Categorization of content and even site structure can be put in the hands of users. Instead of trying to imagine in advance what categories ought to exist, or re-filing everything later, you, the admin, can spend your time on more important things, like reading Summer of Code posts about what's on its way for Drupal!

My project definition says that I still got to document the specifics of SVN and CVS (git has been taken care of). Coming from the KDE camp, I'm already acquainted to Subversion to a certain degree, as the whole huge KDE repository switched from CVS in May 2005. (No one, including the SVN admin, did regret the switch).

Subversion (SVN) came up as a replacement for CVS - motto: "CVS done right" - and incorporates its centralized development methology and its straight-forward workflow, while improving on its weak parts. Compared to CVS, Subversion features good stuff like atomic commits, renaming, serverless diffs, symlink support and version-controlled directories, to name the most popular ones. It fulfills its role as a drop-in replacement brilliantly and has kinda deprecated CVS, at least for newly installed repositories. (That, of course, doesn't stop Linus Torvalds from claiming that centralized development methologies are outright wrong.)

So I volunteered to help test the MSSQL database driver for 5.x and 6.x-dev. Right now Souvent22 is trying to stabilize the install script. So the routine for everybody is:

while (mssql install path != stable) {
1. Checkout DRUPAL-5-1 HEAD
2. Apply mssql patch
3. Delete all the stuff in the test vdir and put in the fresh HEAD
4. drop everything in the SQL Server test database
5. Go to Drupal install page
}

Now after a few iterations this is going to become tedious. So this is what will eventually replace it:

This is copied from my current project site:

Week one of Google SoC 2007 is already over and I'm off to a great start of my SMS Framework project. I've begun developing the gateway side of the API. I've designed it so that additional gateways can be created and install like standard modules. Gatway modules implement hook_smsframework_info(), which returns an array containing information about the gateway(s) the module enables. The information includes the gateway's name, callbacks (for validation, sending, ect.), and a form for configuration.

I cannot believe week one is over!

Following are quoted from the project specification [1] posted

Project Description:
A package of modules to restructure to implement the auto-completion through AJAX and refining the way filtering is done. The project, when all the options are selected, will enable the user to complete the links dynamically and along with the background architecture it will be done in a structured way, thus further extensions and configurations for personal preferences will be made effortless.

Details – Deliverables / Timeframe

Like I said on the the DAST wiki page http://groups.drupal.org/node/3913 DAST is an implementation of a automated build process for Drupal sites. "Build process" is not a term you hear normally associates with websites, but any dynamic web page needs software which renders the final markup and script which gets delivered in the user's browser. A site running on Drupal is a complex piece of software. Building a Drupal site is complex enough to require a tool to automate the process, especially if you're a developer or tester. One important advantages of having a tool to automate the build process, in addition to lessening the toil of overworked Drupalites, is that it is a repeatable process - you can't forget to do something when building a site which leaves you cursing 1.5 hours later when you finally figure out what you forgot to do. DAST will build a Drupal site exactly the same way every time.

The process of creating a Drupal site can be viewed as a pipeline where code assets and configuration move through different stages until the final build output is successfully produced. The software which provides the framework for constructing this pipeline is Phing (PHng Is Not Gnu make) http://www.phing.info