Tuesday, March 13, 2007
by Thad Smith

If you enjoy your music over the web, this should be of interest.  The Copyright Royalty Board has raised its rates on streaming broadcast.  A number of these companies would have to pay more than 100% of their total income.

Wired News

Here is a some information posted about the proposed pricing:


The new rates, just announced today, are retroactive to 2006, and increase rapidly each year. The rates per performance are as follows:

$0.0008 in 2006
$0.0011 in 2007
$0.0014 in 2008
$0.0018 in 2009

At first glance, those seem like fairly small numbers: eight ten-thousandths of a dollar, eleven ten-thousandths of a dollar, and so on. When you actually do the math, however, you see the truth revealed. The average radio station plays 16 songs in an hour. Under this system, that would be equivalent to 16 performances.

0.0011 x 16 = 0.0176

Still a fairly small number - under two cents. But now assume this station has 1000 listeners. That means that, in one hour, the station would be billed for 16,000 performances.

0.0011 x 16000 = 17.60

That’s $17.60 an hour. Now we’re starting to see how expensive this truly is. Multiply that by 24 hours a day.

17.60 * 24 = 422.40 


$422.40 a day. But there’s 365 days in a year.

422.40 * 365 = 154176

$154,176 for the year in performance royalties alone for a station with 1000 listeners. And that’s just for 2007: it gets even worse. In 2008, the cost rises to $193,536 for the year. In 2009, it goes up to $248,832. Even for a much smaller station, the royalties owed are huge.

Of course, these figures don’t include the other set of rights that Internet radio stations are required to purchase, which must be licensed separately from an agency like SESAC or ASCAP, or the cost of bandwidth and server capacity. When you add all these costs together, you can easily see why nobody, save perhaps a megacorporation like AOL or Yahoo, could afford to pay these rates.

Posted on Tuesday, March 13, 2007 9:20:59 AM (Eastern Standard Time, UTC-05:00)  #   Comments [1] | Trackback
 Monday, March 12, 2007
by Thad Smith

Source Code

This post is a repeat of the presentation I gave for the Pee Dee Area .NET User Group this past September.

Ever wanted to take some standard code and place it around a method, maybe a way to time the method, or use a database connection without creating one in each method.  Yes, you can use a try..catch..finally block and make calls to some other methods, but how is that on managing the connection?

So, how do we pull this off in .NET?  With the use of a few interfaces and classes from System.Runtime.Remoting and 4 custom classes we can accomplish our goal.  We start with our base class which we will descend from ContextBoundObject and decorate with our InjectionAttribute (descendant of ContextAttribute).  The ContextBoundObject will create a transparent-proxy which receives all the invocations of the target.  It then serializes the call stack and passes it to a real-proxy (which it also created).  This real-proxy calls an implementation of IMessageSink.

The following is a list and brief description of the class's responsibility:

InjectionAttribute: ContextAttribute
This attribute is used to decorate InjectionBase.  This attribute allows all methods and field-setters to be injected.  This attribute will be used to add an InjectionProperty to the context. 

InjectionProperty: IContextProperty, IContributeServerContextSink
This class is used to insert a new message in front of the current message chain and check the context.

InjectionSink: IMessageSink
This class is used to process the method invocations of the sink chain.  We limit our injection to only methods. When creating an instance of InjectionSink a reference to the next message sink is passed in so that all the sinks can be chained together.

[Injection]
InjectionBase: ContextBoundObject
The class where we bring everything back together.  This class contains the 4 abstract methods we will use to inject our code.  PressProcess, PostProcess, ProcessException, and ProcessSuccess.  These methods will be called from the ProcessMethod which is responsible to invoking the method.

We know create base class implementations of InjectionBase.  There are 2 included in the source, MyClass.cs that demonstrates the basic use and DBInjection.cs which implements a database connection.

The following is a create step-through of what occurs when creating and running a method.

InjectionBase ib = new InjectionBase()
Before the class constructor is called the framework instantiates InjectionAttribute and calls the GetPropertiesForNewContext passing a reference to IConstructionCallMessage.  In this method an instance of InjectionProperty is created and added to the context.  Now InjectionProperty.Freeze and InjectionProperty.IsNewContextOK are called.  Finally, the contructor is called.

ib.DoSomeMethod(param)
Calls InjectionProperty.GetServerContextSink through the IContributeServerContextSink.  This returns a newly created instance of InjectionSink which is used to call InjectionSink.SyncProcessMessageInjectionSink.SyncProcessMessage fires the ProcessMessage on the InjectionBase which invokes our method and injection.

Posted on Monday, March 12, 2007 1:45:34 PM (Eastern Standard Time, UTC-05:00)  #   Comments [0] | Trackback