Partager via

MIX07: Extending the Browser Programming Model with Silverlight

  • Article

Silverlight implements isolated local storage on the client.  Currently in the Alpha, the storage is limited to 1MB per web application and is keyed to the full URL of the XAML/HTML page.  That means for this alpha release, two pages that are part of the same application served from the same domain will have separate isolated storage.  In later beta releases, support will be added to allow configuration of isostorage quotas by users or corporate configuration profiles.

Isolated storage is stored outside the browser cache.  This suggests to me that the lifetime of the data in the isostorage is independent of the browser cache settings - isostorage won't be wiped out when the user clears the browser cache.

Silverlight running in different browsers on the same machine will use the same isostorage area on the machine.  If the user fires up your Silverlight web app in Safari on a Mac and your app writes something to isostorage, then if the user later fires up your Silverlight web app in Firefox on the same Mac, your app will find the data it wrote into local storage earlier in the Safari session.

Isolated local storage is not strictly protected on the local machine.  It's stored in the hidden App Data subdirectory in the user private directory.  A determined user can drill down into this directory and possibly muck with your app data files.  If you're wanting to write sensitive data to the isolated storage that you want to trust has not been mangled by the user, you should consider encrypting the data.

Silverlight provides scriptableobject wrappers for managed code to access JavaScript objects and DOM elements, properties, etc.  When serializing JavaScript data into managed code, you can use CLR generics to instantiate the JavaScript data in strongly typed collections on the managed side.  (strong types! generics! compiler-checked code! Yay!)  For example, instead of implementing a GetProperty method that returns integer, and another one that returns double, and another one that returns strings, they've implemented only one GetProperty method as a generic method whose type parameter defines the return type you want back.  foo.GetProperty<string>("name"), for example.

In the current 1.1 Alpha release, directly calling from managed code into JavaScript is not yet implemented.  However, managed code can invoke events that will fire on the JavaScript side, so you can at least cobble together a way for the managed code to invoke code on the JavaScript side until the real method invoke marshalling is implemented.  JavaScript can call directly into managed code that is tagged with the scriptable attribute.

Silverlight provides an OpenFileDialog functionality.  It manages the UI of prompting the user to select file(s) on the local system and providing them to Silverlight code.  The UI uses the open file dialog of the native OS, so that Mac users see Mac file open behaviors while Windows folks see Windows File Open dialogs.

The filenames returned by OpenFileDialog are stripped of all path information to minimize accidental disclosure of sensitive info that might be embedded in the file path, such as the user's login id.

Files selected by the user and returned by OpenFileDialog can only be opened by Silverlight code in read-only mode.  This is also for safety reasons.  Neither OpenFIleDIalog nor isolated storage ever allow web app code to write to arbitrary locations on the local machine.

MIX07

Watch the video of this session at MIX07

Comments