Maintaining local asset cache

I'm writing a GUI remoting client where the server defines and executes screen and a small GUI application visualizes this on the client. I know this sounds a lot like a website and there will be a web client to this system, but for now I'm focusing on the WPF client implementation.

Part of this system is that I need to synchronize assets between the server and the client. The server has all assets store in a .zip file or as a directory structure on the file system; I haven't decided yet. These assets may change: assets may be added, removed or modified. These modifications need to be synchronized with the client.

The problem I have is how to store these assets on the client. I have come up with the following requirements:

• Assets are keyed by path like keys (e.g. Images/Icons/16/add.png);

• A CRC32 must be maintained per asset to detect chagnes;

• There will be roughly 100 to 200 assets;

• Size of the assets will range between 1 KB and 500 KB (only one or two); medium size is 8 KB; mostly .png image files;

• Since loaded assets will be cached in memory, retrieval doesn't have to be super fast;

• Since assets don't change often, updating the local cache doesn't have to be super fast.

I have thought up the following approaches:

• Fil开发者_如何学JAVAes on disc. This has the following advantages:

  • Easy to implement;

  • Fast update and retrieval;

  And the following disadvantages:

  • Many files "somewhere" on disc;

  • Not possible to store meta data (CRC32);

• Storing files in a .zip file. This has the following advantages:

  • Well defined storage mechanism with good .NET support;

  • Maintains a CRC32 for me (I believe);

  And the following disadvantages:

  • Update and retrieval of random files is relatively slow (I believe);

  • Not possible to store extra metadata (don't know if I'm going to need this though);

• Storing files in an SQLite database. This has the following advantages:

  • Well defined storage mechanism with good .NET support;

  • Allows all kinds of metadata to be stored;

  • Fast update and retrieval of random files;

  And the following disadvantages:

  • May be completely overkill;

  • I'm worried about binary support with SQLite.

My question is 1. am I overlooking an obvious alternative and/or 2. what approach would be the best.

Personally, I'd go with the SQLLite (or MySql, which is open source and free).

In my experience, even small apps have a way of growing into large apps and you'll be glad you used the correct technology, even if it's overkill at the beginning.

Went for the KISS approach: just downloading the entire resource file to the client.

Resource libraries won't get that big, 1 MB to 2 MB. Entire .zip file can be checked for changes with a single hash and updated only when changed. Since this won't happen often (at most once a month), this won't be a problem.