Aug 15, 2011 at 4:17 PM
Edited Aug 15, 2011 at 4:21 PM
>Almost everything is possible...
Haha, I fully agree :)
>Even with a RPC abstraction layer Zyan will not be compatible
>to these other RPC frameworks because it completly encapsulates them.
No, compatibility is not the goal.
The goal is to provide Zyan services (authentication, event handling, LINQ support,
MEF integration) on top of other RPC frameworks meeting certain simple requirements.
>But what minimum set of features can we expect that every RPC framework has?
If Zyan had the following features:
- ZyanDispatcher runs on both sides of the connection: #1090
- Zyan can pass references to remote components, similarly to ObjRefs in Remoting: #766
then the requirements are minimal.
I.e., we could use any RPC framework that allows calling IZyanDispatcher methods.
Plain old web-services, perhaps.
>Zyan currently makes rich use of .NET Remoting features for delegate and event support.
You are probably talking about DelegateInterceptor?
DelegateInterceptor is an MBR object, which is handled by Remoting infrastructure automatically.
We can create DelegateInterceptor and pass it over the remoting channel, and the rest is done for us.
But if we enable Zyan to handle remote component references and register new DelegateInterceptor
instances on-the-fly (for every event handler), then we probably could mimic this behavior using any
simple RPC layer, just like custom serialization handlers process non-serializable classes.
>Before we start to deconstruct the current Zyan architecture and plug some abstraction
>layer in, we should make some tests to get an overview about the needed effort.
Yes, of course.
I don't think we should invest much time in this feature in the nearby future.
I'd suggest to schedule it for, say, Zyan 4.0 :)
Instead of Silverlight port.