[Freeswitch-users] Subscribing to events in managed C# / .NET

[Josh Rivers]

On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <mgg at giagnocavo.net>wrote:

>  Right off the bat: there can be tons of cleanup and refactoring, no doubt
> about that. Much of the current code is to satisfy my needs in production,
> which it does very well.
>
The current base doesn't have anything wrong with it for sure, in fact, I
learned a good bit about PInvoke. AppDomains, and In-Process Remoting in the
last week.

My refactoring had the following goals (in no particular order)
 - Testability - I'd really like to see a decent unit test suite on the more
module so that we can change it with confidence. Also, it's been drilled
into me that a testable design is a good design.
 - Clarity - Where possible, I extracted blocks of code that served a
particular purpose so that purpose could be self-documenting in the method
calls rather than mixed in.
 - Modularity - I wanted to make it easy to remove or add alternative
behavior to the managed.dll.


> I’m a bit hesitant to go too far from the FreeSWITCH core as far as
> architecture goes. For instance, I’m not quite sure why’d we have our own
> managed logging subsystem that allows them to plug in other things that
> aren’t part of FS. Either they should use the FS logging system, or use
> their own such as log4net. Or perhaps I don’t see why we’d want this
> behavior.
>
I completely agree, with the following caveats:
1) I'd like to see things testable. It's very hard to do isolation testing
with classes making direct calls out to a static Log class that in turn
pinvokes out to unmanaged code.
2) I'd like to allow folk to make changes to the default behavior
(optimally) without recompiling managed.dll.

One thing at issue here is that there are two principal purposes for
managed.dll. The first is to provide an interface into unmanaged code. The
second is a module/plugin extensibility framework. The first purpose should
absolutely provide the thinnest layer possible. The second purpose is very
likely to need a lot of change and adaptation as people come up with
development models that they would like to follow in using freeswitch. The
extensibility framework should be mostly managed code, coded to interfaces
for mock-ability and testabiliy. It should also be able to just push it out
of the way and hook your own extensibilty framework in instead.

>  Going away from the core as far as adding .NET specific features (like
> look at the static ManagedSession.Originate that takes hangup delegates, or
> the “nice” wrapper for Log (Write and WeiteLine, with an enum instead of a
> string) are keeping close to the core, just adding a tiny bit of API
> cleanup. FreeSWITCH exposes a lot of strings, and while maybe that’s
> important for some languages, .NET users are going to expect stronger
> typing. But I don’t think these types of things get people away from
> FreeSWITCH much.
>
No disagreement here. I would like to see these things made available by
interface rather than concrete implementation. It's currently not possible
to test a plugin without loading it into FS. That precludes automated
testing, and leaves a pretty big round-trip to test a tweak. I'm a sloppy
coder too, so I'm always introducing interesting regressions, and that's why
I like doing my testing without having to bring up a full process :)

> Things like making a published SOAP interface for FS seem not really
> related to mod_managed. They can easily be done as 3rd party plugins, or
> convince the core FS team that exposing via SOAP via mod_managed is the way
> to go. Also keep in mind that the majority of users are on Linux, so that
> rules out WCF and some other fun stuff that only works on the CLR – I’d say
> it all has to work on Mono.
>
This kind of stuff is definitely beyond the scope of mod_managed. Although
there is a slippery slope since we're building in an extensibility model. I
don't think a WCF host, or a winforms host, or any of that should be baked
in. Rather, I think we should provide the hooks for adding such a thing. If
somebody wants to build ESL via WCF, why should they need to leave managed
code? If the module system is general enough, then such a thing should just
be a module.
(BTW, I think WCF-Mono is getting there
http://www.mono-project.com/WCF_Development)
Absolutely, everything in mod_managed and managed.dll should run on mono and
the CLR. However, there shouldn't be any reason that a Win-only developer
can't build a complete FS application framework that plugs in and only runs
on Windows.

> As for all the rest of it, can we talk interactively, perhaps with other
> users interested in mod_managed? Reading over your email, I think I’m not
> understanding many of the use cases that are being fixed.
>
I'd be very glad to get a discussion going. I definitely haven't covered all
of the issues here.

-Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090923/72445c47/attachment-0002.html