QVCS Product Family Newsletter - January 2007

Publication date: January 16, 2007

Blog Highlights -- Of iMac's and Renames
QVCS-Enterprise -- Compatibility Issue with QVCS/QVCS-Pro
QVCS-Enterprise -- Improving the Authorization Model
QVCS/QVCS-Pro -- Update in 2nd Quarter.

Blog Highlights -- Of iMac's and Renames

Producing a cross-platform product is one of key goals I had in mind when I first created QVCS-Enterprise. What better way to realize that goal than to add Apple's MacIntosh as one of the supported platforms for QVCS-Enterprise.

This blog entry:

http://www.qumasoft.com/weblog/archives/12-01-2006_12-31-2006.html#158

provides some details on dipping my toe in the MacIntosh waters.

Also on the Enterprise 'TO-DO' list is addition of support for file renaming, moving files, renaming directories, and moving directories. It turns out these are tricky features to implement. Some details are provided by these blog entries:

http://www.qumasoft.com/weblog/archives/12-01-2006_12-31-2006.html#157
http://www.qumasoft.com/weblog/archives/12-01-2006_12-31-2006.html#161
http://www.qumasoft.com/weblog/archives/01-01-2007_01-31-2007.html#164

QVCS-Enterprise -- Compatibility Issue with QVCS/QVCS-Pro

There is a compatibility problem between archive files created with QVCS/QVCS-Pro and QVCS-Enterprise. The problem is obscure (at least for those of us living in the US) and appears only when the original archive files' user names contain non-ASCII characters.

The basic problem is that the QVCS-Enterprise Java code doesn't correctly handle existing QVCS/QVCS-Pro archives in the circumstance that those archives have any non-ASCII characters in their user names -- i.e. if any names that appear on the access list or modifier list have non-ASCII characters, then the existing Java code misbehaves.

The basic issue is that for those kinds of characters, the QVCS/QVCS-Pro C++ code encodes them using an ISO-8859-1 encoding. The Java code decodes those bytes using the platform default encoding (typically UTF-16). Then when the Java code goes to write the new archive header, it uses UTF-16 encoding for the byte stream written to the file.

This results in a different length for the access list than what was read and what length the header indicates -- resulting in a corrupt archive file. The workaround is to not use existing QVCS/QVCS-Pro archive files. The problem came up as a result of a user in Norway trying to migrate existing QVCS/QVCS-Pro archives for use by QVCS-Enterprise.

If enough users run into this issue, I could write an encoding migration tool that would make it so a user could manually migrate archives between the different encoding schemes in order to go back and forth between the two different encodings.

However, the current plan is to continue with the current workaround. For those users who have non-ASCII characters in their user names: Don't use existing QVCS/QVCS-Pro archive files with QVCS-Enterprise.

QVCS-Enterprise -- Improving the Authorization Model

Along with rename support, QVCS-Enterprise 2.1.x will include an improved authorization model.

The current QVCS-Enterprise authorization model is very course-grained: If a user is assigned the WRITER role, the user can perform any kind of update to an archive file. Suppose you want to have a user who is allowed to check-out and check-in files, but you don't want them to have the ability to apply a label to a file? Or suppose you have a user who you do not want to be able to perform any kind of development, but you do want them to be able to apply labels and remove them? The current authorization model does not allow this kind of flexibility.

The authorization model included with the 2.1.x release provides this kind of flexibility. The new authorization model allows the ADMIN user to define new roles (in addition to the current built-in READER, WRITER, and PROJECT_ADMIN roles). When creating a new role, the ADMIN user can define which actions users who are assigned that role will be allowed to perform.

Existing users who don't need the additional granularity won't need to do anything -- the behavior will be the same as it is today. Users who need more control over which users can perform some activity will be able to define new roles or edit the existing READER, WRITER, and PROJECT_ADMIN roles to tune that behavior.

QVCS/QVCS-Pro -- Update in 2nd Quarter.