clipka <ano### [at] anonymousorg> wrote:
> (many things)

I agree with he principle wholeheartedly; I nearly always prototype complex
things in an atomic fashion once I hash out the models mentally, in order
to sanity check my work.

I do the same when extricating legacy software algorithms from the
festering bulk from whence they originate.

Once you separate the routines which are responsible for doing the work
from whatever horrific matrix of septic horrors and sad excuses for OO
design patterns within which they were entombed, you are then free to
implement a plugin based architecture.

At my current place of employment I wrote a sort of meta framework.

Typically I use interface driven design with a pair of interfaces which
describe the module in question:
Lazy<IFooPlugin, IFooPluginMetadata>

Then I use MEF and a number of design patterns that allow me to represent
arbitrarily complex hierarchical relationships and access any given subset
in O(1) time, due to the interface pairs existing in a concurrent
collection and the hierarchy relationships enforced by interface.

Long story short you end up with a strongly typed system that supports
backwards compatibility, dynamic plugin loading and hosting, the ability to
compose functionality, versioning, business logic tracking and execution
tree reproduction for rerunning records, on the fly extensibility without
recompilation, etc..

With the WCF plugins that run on the same framework, you have dynamic
content type handling with no work required by the dev to support it, you
just decorate your service method, all the capabilities of the above,
dynamic REST/SOAP support, spooling of services based on load, across
servers....no hardcoded URIs but instead you request one and if an instance
exists that meets your spooling criteria you get the URI otherwise it
spools it...new servers can be stood up in under 20m and they immediately
become part of the global pool for load balancing on their own.

And more.

I wrote an extension to my framework that finds all plugins of the same I/O
type and loads them in a UI like Visio but node based, so you can compose
new programs from deployed plugins as easily as building a flow chart. It
makes an XML file that goes to the server, the UI host reads it and creates
a UI for input, and voila, business users can compose new apps from extant
plugins with no coding knowledge, letting them use the plugins written by
any BU and thus save time and testing and each new plugin benefits all
BUs...it uses dynamic generation of Func<> behind the scenes and chains a
call stack together with them using lambdas and TPL.

It is actually incredibly stable and fast as heck. :)

But I digress...my point was I guess to illustrate my love of well designed
code and systems architecture. :)

Like you have mentioned, some sort of truly modular architecture can be
implemented for Pov, where all parts can be replaced and new modules can be
dynamically inserted into the call stack of all parts without recompilation
so we basically have full composition capabilities via polymorphism, using
CoR, strategy, decorator, (and others).

Throw a nice node editor in there and we'll be in business. :-D

Folks will be able to add new algos for rendering pipeline, effects, domain
scripting languages and essentially any and everything.

Obviously the easier it is to do stuff like that the more likely it is
folks will in fact do it, which would be awesome.

Ian

Post a reply to this message