SoC

So public/private file handling has been progressing pretty well. I've still been having some trouble fixing uploads in HEAD and the changing code base has made this a challenge. However I've become much better at debugging and I'm quickly become a bazaar wizz. The project is still on target to be completed soon and the code should be operating properly quickly. For those interested in the progress you can use bazaar to check out the code from http://drupal.codeincarnate.com.

In the next one or two days I'll release the last version (before SoC end) of my XMPP library, and before that I'd like to have a few people test message delivery to their jabber accounts. This test does not involve Drupal just yet, but it perfectly mimics what my Drupal module will be doing once I update it to work with the latest library revision. As I posted on my development site, this demo would be most useful if people ran it against servers other than Google Talk or Openfire.

Much of last week I didn't have time to work on my summer of code project. I spent a lot of my time on the phone trying to find a house to live and people to live with for this coming fall semester at college (Which starts at the beginning of September). I also had to spend time on the phone to get my classes ironed out and financial aid. I also had to spend some time on a drupal project outside of my summer of code project due to my funds running a little short and bills being due. And I also had to due some phone interviews for job positions after my graduation this coming December.

This week was dedicated for the most part to the server implementation. As of today, my XMPP client is essentially finished and the server just needs a few more hours of work. Today I started writing the implementation of server dialback and router extensions, which are the last two pieces needed for a working server. My hope is wrap up the library in the next three days, followed by a day or two for testing and, of course, writing examples and documentation.

The last 2 weeks I spent a lot of time in adding paging mechanism to the tree structure, in separating the tree structure as a own form element type and in adding of a form for editing data from a specific term.

Just a development snapshot before the 0.2 release - Download http://www.abeharry.info/stuff/DAST-0.2-dev.tar.gz

Unpackage anywhere like usr/share/DAST There is an httpd.conf in DAST/src/tests/etc/tasks/. Now run from DAST:

./bin/dast -f ./src/tests/etc/tasks/eApacheHttpdConfTaskTest.xml

The httpd.conf will be updated with new directives, sections, and embedded sections.

This snapshot has all dependencies bundled so don't download the dast-deps package. You must not place this snapshot in the same location as earlier releases

This week, my Version Control SoC Project saw further completions of the API functions' implementations (the API itself is completely implemented now, if I'm not mistaken) and the creation of extendable admin screens, mainly for repositories for now. There's now a list of repositories separately for each version control system, and each backend can easily customize creation, editing and display of repository information by means of hook_form_alter() and a small number of more specific hooks. Repository management is now at the same level of functionality as the one in cvs.module, only that it's generic at the basics and other backends can without much effort provide their own custom stuff, just like CVS provides CVS modules and different methods of commit information retrieval. Sure, you want screenshots:

I've posted an update on the SMS Framework project and a screencast on the Development Seed blog. It introduces some of the new functionality that I've implemented using the API.

Well, files have been coming along well. Full working private/public upload and download functionality is nearly working and a alpha release for testing will be coming in the very near future. Most of the work left that remains is with file_set_private which is a very important function in the entire scheme of things. As always if you want to get the code bazaar can be used, just point it at http://drupal.codeincarnate.com. Things may be a little delayed because I'm turning 21 tomorrow. Bottoms up!

This is the second in a series of articles on Phing the fantastic PHP application build framework which DAST extends. Although DAST will come with quite a number of ready-made scripts, its real power lies in providing the foundation for Drupal developers, testers, admins and distro maintainers to quickly and easily create their own build scripts. A distro builder may choose to bundle their build script which painlessly downloads the required modules, sets up the user's database, and runs basic smoke tests to verify the Drupal web site on the user's web server is ready to use. DAST applies the concept of a software project build to creating Drupal sites and has a wide range of uses - See the upcoming article "10 cool Drupal things to do with DAST."

In Part I I looked at the basic structure of a Phing build file - projects, targets, and tasks. I posted a use case http://groups.drupal.org/node/4477 which is now implemented as the dast-patch build file for automating creating patch test-beds. In Part III we'll look at how this build file was implemented using the stuff we've covered before. First I'll wrap up this dive into basic Phing with a a description of properties and types which are present in every useful build file, mappers and filter chains which are used for file I/O, and the ever-important conditional execution and iteration. Remember Phing is a feature complete implementation of Ant - all concepts in Phing are identical to their Ant counterparts, so if you're familiar with writing Ant build files, using Phing will be easy like Sunday morning.