Monday, December 1, 2008

Fast Persistent Data Storage Idea

There are several types of data storage technologies out there. The hard drive is cheap but slow seek speeds kills it when random access occurs, and a physical impact can literally kill it. Flash memory is faster then a hard drive and can withstand physical impacts but it has a limited lifetime do to the number of writes it can take. Random access memory like ddr3 is even faster then the flash memory and does not have lifetime issues, but is volatile meaning it looses its data when it loses power.

A while ago I thought of an idea on how to have the speed of ram but have it persist like flash. Its rather simple really, just combine on a single chip or board a equal amount of ram and flash and a capacitor to power the ram long enough to write the rams contents to the flash.

So this is how it would work:

When powering up the device (ram, flash, capacitor, and controller) would copy the contents of the flash over to the ram and charge the capacitors.

Until the capacitors are fully charged access to the drive would be denied.

When the device is accessed all reading and writing is done to the ram.

When the device looses power it copies the Rams data over to the flash. (Could add logic to only copy what has changed.)

This increases costs quite a bit but it gets rid of all the weaknesses of known storage technologies. It will be shock resistant, fast, long lasting, and its data persistent.

Porting Mono's SslStream to SilverLight

I have recently run into another problem with Microsoft’s stripping of the silverlight runtime. This time I was looking into using Sockets, because of the crippled WCF implementation. But sockets have been badly stripped. The only thing in the System.Net.Sockets namespace is the Socket class. No TcpClient no UdpClient and no NetworkStream. The System.Net.Security namespace is also gone. Meaning no SslStream.

With no SslStream and a sorely lacking implementation of WCF, silverlight is pretty insecure. Not in the fashion of a computer virus but in how FTP transmits passwords in clear text.

I’m not sure what kind of applications Microsoft expects people to write without being able send files larger then a few megabytes with WCF or to secure their Socket’s data with an SslStream. I’m starting to think Microsoft made a very bad mistake with trying to shrink the runtime so much. I bet people will either write insecure applications and blame silverlight or avoid it all together. Deep market penetration caused by a small download will mean nothing if developers don’t write programs for silverlight.

Anyways that’s enough complaining about the free framework that Microsoft spent a lot of money to write.

A rather simple yet time consuming solution to this issue is to port Mono’s implementation of .Net APIs that are needed. I’m not sure how much effort will be needed, but it should be rather simple to do. Write access to Mono’s repository would be required keep it synced with Mono so that’s not something I can do. Basically you would just sprinkle some compiler directives to exclude classes and methods that are not possible. Also add extension methods to extend silverlight classes that don’t have needed methods. Then write build scripts that compile those for silverlight. For limited subset of classes like the NetworkStream it should be relatively easy to port them to silverlight. Classes like the SslStream will require more effort because of its reliance on Certificate stores.