This project has moved and is read-only. For the latest updates, please go here.

Could a read only senario use app resources instead of isolated storage?

May 12, 2011 at 1:41 PM

If my needs were read only, could IsoStorageHelper.cs be updated to return BinaryReaders that point to app Resources that installed with the assembly, and forego isolated storage all together? 

Application.GetResourceStream(new Uri(@"/MyApp;component/xxxxxx"UriKind.Relative)).Stream;

In a readonly senario, will it ever need a BinaryWriter?



May 12, 2011 at 1:45 PM

One enhancement in the pipeline is to change the isolated storage strategy to use single files per table and possibly per database. Introduces some more complexity for concurrency but should speed things significantly as opposed to multiple "mini-tables" which cause a lot of overhead on the isolated storage system. With my current resources that is several months off unfortunately.

What you propose COULD be handled by a custom driver. That is definitely possible. Basically all persistence concerns are handed off to the driver, and the driver would simply need to know about the resource stream and have insights into locations within the stream - i.e. offsets for keys and tables, so it could seek to the right position in the stream to deserialize. That is very possible and a great idea - that driver would not ever need a binary writer.

May 12, 2011 at 2:49 PM

But implementing a driver would have changes happen higher up than just IsoStorageHelper.cs right? It would also be a fundamental change to the codebase, correct?

If the only thing I changed were the methods currently inside IsoStorageHelper.cs, would the following be needed if I only used the database in a read only fashon?

 public BinaryWriter GetWriter(string path)
public void Purge(string path)
private static void Purge(string path, bool clear)

May 12, 2011 at 3:31 PM

No, the driver architecture specifically allows for extensibility points to the engine without changing the core.