Revise project architecture

[GoogleCodeExporter]

A lot has changed since the original architecture has been defined.
During implementation the core steadily shifted from host side to target side.
As a result, some existing code became overdesigned or is now just in the wrong 
place.

The system is now quite close to being somehow functional for native targets, 
therefore it might be a good time to revise the existing architecture.
A revised architecture would ensure that in the future the virtualization 
engine can be easily expanded and that new features can be added without 
unnecessary efforts.

At least the following areas need attention:

- Redefine Core project.
Core contains a mix of code, targeted at either the host or server side, or at 
both sides.
Perhaps the current Server project should be part of the new Core, while the 
current Core should be split up into the existing and/or new projects.

- Revise database access methods.
Is there still a point in only allowing the host to access the database? Doing 
this causes (unnecessary?) expensive transfers of data between host and target, 
while the host side doesn't really do anything with the data read and sent. One 
of the original reasons for using this system was to avoid conflicts between 
the virtualization engine and its own database access.

- Revise database access API.
Currently a generic command based system is used.
During development of the virtualization engines, database access has become 
significantly less complex (e.g. the filesystem engine doesn't use any database 
anymore). Therefore it should be investigated if the current system is 
overdesigned for its current goals, and/or for its future goals.

- Revise purpose of Watcher.
Can the Watcher be merged with the Host? Needing two processes to support a 
single target process is simply not justifiable.
The original purpose of Watcher was to ensure having a simple/stable process 
which would always ensure a clean GAC, in case the Host would leak some garbage 
there.
It should be investigated if, as an alternative, it would be save to let the 
watcher run in a separate application domain in the host process.

- Revise lifetime of Host.
Is it necessary to leave the host running once the target process is set up?
Note that this conflicts with the previous statement, since combining both 
statements would result in leaving target process' running on their own.
Is this safe? How will a clean system be ensured?

Original issue reported on code.google.com by simon_al...@hotmail.com on 2 Nov 2010 at 4:54

[GoogleCodeExporter]

A lot has been done already:
- Host.exe has been merged to Manager.exe
- Core and Server projects have been renamed to Host and Engine (Note: Don't 
mix the new Host.dll with the old Host.exe)
- Now there's a clear line between the Host and Engine projects
- Logging and Databases have been moved to the Utilities project
- The "core"-weight has shifted from Host to Engine
- Database access is now done entirely on engine side (not stable yet due to 
problems with SQLite dependencies)
- No need to completely revise database access API, it might become useful for 
e.g. supporting logging to a database file sometime in the future

Pending:
- Revise database engine (Is SQLite usable for this project? Is there any 
database library available which doesn't have any unmanaged dependencies?)
- Clean up the engine startup logic (IProcessSynchronizer interfaces are a mess 
now)
- Update documentation and comments to use new terms
- Revise purpose of Watcher
- Revise lifetime of Host

Original comment by simon_al...@hotmail.com on 14 Nov 2010 at 6:39

• Changed state: Started

[GoogleCodeExporter]

SQLite is now replaced by SQL CE
- SQL CE is used because it just works, in contrast to SQLite, DeveelDb, ...
- Utilities project now contains database implementations for multiple db 
types, this needs to be cleaned out

Engine startup logic must certainly be revised.
One major problem is that the complete database initialization and database 
read is currently done in the ProcessEntryPoint constructor. As a result any 
exceptions thrown in this error prone task are untraceable and result in a 
hanging target process.

Original comment by simon_al...@hotmail.com on 6 Dec 2010 at 6:03