Silverlight, ActiveX, AIR, Sandbox, and Offline

1. Silverlight 2 stand-alone with ActiveX

Silverlight 2 stand-alone html application (it is better to change the .html to .hta, the host is MSHTA.EXE), using javascript (file mode, so full trust) to call activeX (note that this approach is not cross platform).

http://www.galasoft.ch/mydotnet/articles/article-2008042301.html
http://geekswithblogs.net/lbugnion/archive/2008/04/24/silverlight-running-standalone-full-trust-applications.aspx

http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/27/how-to-make-silverlight-be-air.aspx

2. If the requirement is not offline, but to access files and ports, can use special ActiveX with javascript.

3. Silverlight 3 OOB is not that useful

--a. Silverlight 3 OOB is within browser sandbox, so, cannot access file etc.
--b. Silverlight 3 OOB (out of browser) cannot use html/javascript, so, it cannot be used together with the hta technique.


4. The above is not cross-platform (but for intranet, it is good that it does not need to install any “extra” stuff), for that, AIR is the way to go.

5. Is it possible to use both AIR and pure Silverlight3? Not sure: (i) Can Silverlight3 be invoked from AIR? (ii) Silverlight cannot invoke AIR (sandbox), but it can save to the storage, and AIR can poll that. (iii) Silverlight cannot mash up AIR. (iv) AIR perhaps can mash up Silverlight. As a result, it looks like we can use AIR as the “shell” (base application), and invoke Silverlight screens (because it is in sandbox, so, it does not know other instances; so, the shell must be very lightweight and can be instantiated many times without performance issues).

6. For Serial port etc, it needs a generic "proxy" that translates port to socket(). Javascript can then use socket. Note that this makes it not portable. So, if we do not need offline feature, then, we can simply develop small ActiveXes to access things out of the sandbox, and use Silverlight for UI, and use javascript to glue things togother.

The so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the process

The so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the process. Both of them are about three things:

1. use cases
2. data fields
3. architecture use cases (transaction-failure handling; network-performance plus offline client, reports, direct database jobs; security, auditing)


Key understanding:

1. use cases: this is the art. The core of the art is to find the representative use cases so that they are only a few but cover all data fields. Also note that they need to be described using UI terms, however, they are use cases -- using UI language and eventually doing UI design do not mean you need to jump on UI design in the very beginning.

2. data fields: this is the science. All computing are based on this, including object oriented programming -- the core of domain model is in data model. However, note that this does not mean you need to jump on database physical design in the very beginning.

3. Architecture use cases. They are use cases. "Architecture" is not magic; they must be organized in use cases. Users can and must understand them -- that is, if you organize them in use cases.