Luckily, those of us who pay good money for DVDs have free software solutions to let us used our payed for product and not force us to download “pirated” copies just so we can view what we payed for.

The region coding in DVDs was designed with the idea that DVD players would always be expensive. You could “change” which region your DVD player was in a set number of times before you could no longer change it.

DVD players can now be bought for $30 (or less). This is what you could pay for a DVD movie. So with economies of scale driving prices down, even if CSS wasn’t completely broken, you can brute force the region coding by just buying 6 DVD players ($180) – less than many of us payed for our first, second or third DVD player.

The same thing will happen with BluRay. You can now get BluRay players for a couple of hundred dollars. One for each of the regions (A, B and C) will cost you less than original BluRay players cost.

So the antifeature of limiting who can watch a DVD/BluRay release is easily broken as player costs come down.

I’d like to coin a new term… anti-anti-features. These are antifeatures (i.e. a feature you didn’t want in the first place) doesn’t actually function properly itself.

The other day, I sat down with a friend to watch a movie. We had hired out a BluRay of a recently released movie, popped it in the player and attempted to hit “Pause”. Why pause? Well… movies often can auto-play and we wanted to fetch a beer, snack and otherwise prepare for the great movie watching experience.

It turns out you cannot pause the copyright notice. So if you’re trying to be good and understand your obligations under the license in which you have received this disc, you cannot actually finish reading them!

Try it – put in a DVD or BluRay and try to read the copyright notice. I bet you that for a large number of discs you cannot do so in the time allowed.

This just goes to show how utterly useless these “no skip” zones are. You will see hundreds of exactly the same notice (one for each disc you view) many, many times (each time you view it) – one would think that after the first, second, third or even 10th time you’d understand it.

Amazingly, under DVD playback software that lets you skip the “no skip” zones (e.g. every DVD player on Linux) it also allows you to pause on the copyright notice and read it.

It is amazing that Final Cut “Pro” cannot actually be used to create H.264 content for commercial (i.e. “Pro”) use!

It’s the same for MPEG-2.

Oh, and if you use it to decode video that was encoded by somebody without the proper license… well, then you’re also screwed. How the heck you’re meant to work that one out I have no idea.

=== modified file 'drizzled/field/blob.h'
--- drizzled/field/blob.h	2009-12-21 08:16:13 +0000
+++ drizzled/field/blob.h	2010-01-18 01:36:48 +0000
@@ -32,6 +32,7 @@
  */
 class Field_blob :public Field_str {
 protected:
+  uint32_t assassass;
   uint32_t packlength;
   String value;				// For temporaries
 public:

and later on….

  if (prgflag & (READ_ALL+EXTRA_RECORD))
    records++;

Feel free to think about that for a second.

(I have an urge to add this to questions asked in a job interview…)

Thanks to the EFF for their E-Book Buyer’s Guide to Privacy.

It also took them over an hour to make the announcement that the flight had been delayed. The screens just flashed “Boarding” for an hour (and they still are).

Delays are fine. Complete and total lack of any communication whatsoever is not.

Simply jumping on a microphone and saying “we’re experiencing a delay, we’ll have more information for you in half an hour” would be better. We seriously heard nothing for a whole hour after “Boarding” had started.

Just a closed door.

Somehow I feel this will be the last time I fly this airline.

Yesterday I talked about the Schema protobuf message format in more detail, and this time I’m talking about the Table protobuf message in a similar amount.

The first time we were loading (then only part of) the table definition out of a protobuf message was way back in January 2009 (I blogged about it too). It was an adventure untangling all sorts of things to get to a much nicer place (where we are now). The code in the server is not perfect… I’ll be the first to admit that some of it is rather strange, but that’s mostly all behind the scenes for people interested in the protobuf Table message!

The Table message has several embedded messages in it too. We need to have information on the Storage Engine, Fields and Indexes (and each of those can have other properties). It is much more complex than the simple Schema message.

Let’s have a look at the basic structure of the Table message:

message Table {

    /* *SNIP* (Here goes the definitions for TableType, StorageEngine, Field, Index, ForeignKeyConstrain, TableOptions and TableStats) */

  required string name = 1;
  required TableType type = 5;
  required StorageEngine engine = 2;
  repeated Field field = 3;
  repeated Index indexes = 4;

  repeated ForeignKeyConstraint fk_constraint = 8;
  optional TableOptions options = 9;
  optional TableStats stats = 10;
}

(We’ve skipped the definitions for the embedded messages for now)

This seems all pretty logical; a table has a name, a type, is in a Storage Engine, has Fields, may have Indexes, may have foreign key constraints, it has some options and statistics (the statistics may go away at some point “soon”).

Let’s have a look at the TableType message definition:

  enum TableType {
    STANDARD = 0;
    TEMPORARY = 1;
    INTERNAL = 2;
  }

It’s pretty simple, the table type is either a standard table (what you get from CREATE TABLE), a temporary table (what you get from CREATE TEMPORARY TABLE) or an INTERNAL table (what you get when Drizzle uses a temporary table during query execution).

Next, the StorageEngine message:

  message StorageEngine {

    message EngineOption {
      enum EngineOptionType {
        BOOL = 0;
        INTEGER = 1;
        STRING = 2;
      }

      required string option_name = 1;
      required string option_value = 2;
      required EngineOptionType option_type = 3;
    }

    required string name = 1;
    repeated EngineOption option = 2;
  }

The main part is the “name” member, which is just the name of the storage engine (e.g. “PBXT”,  ”INNODB”, “ARCHIVE”). We do however have support specified in the StorageEngine message for engine specific options (in key value form). Expect these to be used more in the near future.

Specifying Fields is probably the most complex part of the table message. The Field message looks like this (with many embedded messages):

message Field {
    required string name = 1;
    required FieldType type = 2;
    optional FieldFormatType format = 3;
    optional FieldOptions options = 4;
    optional FieldConstraints constraints = 5;
    optional NumericFieldOptions numeric_options = 6;
    optional StringFieldOptions string_options = 7;

    optional string comment = 16; /* Reserve 0-15 for frequently accessed attributes */
    optional SetFieldOptions set_options = 17;
    optional TimestampFieldOptions timestamp_options = 18;
}

So… what does this all mean? Well, Fields have a type, they’re stored in a format, there’s options attached to them, there may be constraints as well as field type specific options.

The different field types should be fairly familiar by now:

    enum FieldType {
      DOUBLE = 0;
      VARCHAR = 1;
      BLOB = 2;
      ENUM = 3;
      INTEGER = 4;
      BIGINT = 5;
      DECIMAL = 6;
      DATE = 7;
      TIME = 8;
      TIMESTAMP = 9;
      DATETIME = 10;
    }

We also allow fields in different formats. Currently, these are default, fixed and dynamic. The idea is you can tell the engine (or the engine can tell you) how it’s storing the field. This is currently here as a nicety and the users for this are few and far between.

    enum FieldFormatType {
      DefaultFormat= 0;
      FixedFormat= 1;
      DynamicFormat= 2;
    }

The FieldOptions get interesting though:

    message FieldOptions {
      optional string default_value = 1;
      optional string update_value = 2;
      optional bool default_null = 3 [default = false];
      optional bytes default_bin_value = 4;
    }

You’ll no doubt be intrigued by the existence of both “default_value” and “default_bin_value”. Ordinarily, using a string to contain a textual representation of the default value (e.g. “foo” or “42″) is fine. However, for BLOB columns, you can have defaults that aren’t representable in a text string, you need binary data (e.g. the default value contains ‘\0′).

For TIMESTAMP columns, we continue to support DEFAULT NOW() and the ability to update the timestamp column on UPDATE. How is this represented in the table message? Well… default_value will be “NOW()” and update_value will be “NOW()”. It is intended that in the future it will be possible to have arbitrary SQL expressions for these. This does, of course, require support in the Drizzle server.

The default_null bool should be rather obvious :)

Well… that’s enough for today. Next time: more of the Field message!