PHP_CodeSniffer 1.0.0RC3 released with tab support

I've just released the third release candidate of PHP_CodeSniffer. This release contains a few bug fixes, some changes to the Squiz coding standard, and a great new feature to provide support for tab-indented files.

In the past, my standard response to people asking for PHP_CodeSniffer to "support tabs" was to say that PHP_CodeSniffer doesn't do anything to stop you writing standards that use tabs, but the default sniffs that come with it don't support them. But that response also alludes to the fact that PHP_CodeSniffer doesn't do anything to help you if you happen to be using tabs. That has now changed.

PHP_CodeSniffer has a new command line argument --tab-width=4 that will replace tabs inside a file with the number of spaces specified (4 in this case). There is a bit of code checking that tabs are replaced with the correct number of spaces (tabs do not always equal exactly the tab width) so it is not just a straight string replacement. That means there is a bit of additional overhead when checking files, but I don't think it is noticeable.

The benefit of using this option is that you can use all the existing sniffs to check your code and they will not produce errors about tab indentation and alignment. By the time the code gets to them, all tabs have been replaced. This makes it easier to generate your own standard using existing sniffs, and makes it easier to write sniffs as you don't have to take both indentation methods into account.

Of course, you don't have to use this feature. You can still write your own sniffs that explicitly check for tab indentation and alignment.

You can view the full changelog, and download the release, on the package download page.

International PHP Conference 2007

The International PHP Conference has come and gone for 2007. Gergely Hodicska has an IPC 2007 "megapost" listing quite a few of the talks with links to the presentation slides. It was good to see that PHP_CodeSniffer was mentioned in a couple of the sessions:

• Tales from the eXtreme side by Lars Jankowfsky
• PHP Tools and Automation by Stefan Priebsch

Unique lock tokens in MySource4

We've recently moved onto designing the new MySource4 locking system. My work on locking during the WebDAV development lead me to the idea of unique lock tokens, which I had not previously considered for the locking system. I never saw a real need for lock tokens to be unique each time a lock is acquired on a resource, but now I have.

In MySource Matrix, each lock you acquire has a unique system-wide lock token that comprises of the asset ID and a lock type (e.g., attributes or linking). Each time that lock is acquired, the same lock token is generated.

MySource4 uses an alternative system where the lock token is always unique over time by using a UUID. This means that when you acquire a lock, MySource4 will give you this lock token and you will need to supply it back to MySource4 when you save. These lock tokens are very random and cannot be guessed. This is the same way WebDAV clients work.

The real difference in these two systems is trust.

In MySource Matrix, if you are logged in as the same user that acquired the lock, you can use that lock to save content. You do not need to supply a lock token so you can log into two different browser sessions and happily lock and save content in each.

In MySource4, if you acquire a lock in one browser, you cannot reuse that lock in another. The editing interface (acting as the client here) has to send the unique lock token back to MySource4 to save the content. The editing interface in the second browser will not know the correct lock token, and so the save will fail.

That's really all behind the scenes, and users don't need to worry about that when they lock content. In fact, users never have to explicitly lock content in MySource4, so even though the locking system is more complicated, the end-user experience is greatly simplified. It does stop one important conflict from occurring though; two editors logged in as the same user overriding the content of the other.

Although it is highly discouraged, editors will sometimes log into the system using the same username and password. Even worse, this can happen with the root account. When this happens, the locking system has no way to differentiate between the two editors, and so the locks of one become the locks of the other. This can lead to a situation where both editors are editing the same content at once and the last one to save wins.

In MySource4, once the first editor locks a piece of content, the second editor will see the content as locked because they do not have the correct lock token. So even though these two editors are logged in as the same user, they are treated as different users by the locking system.

This small change will lead to less chance of editing conflicts, including any editing that might take place in a replicated editing environment.