There are a few other things I can think would be nice additions to
mod_managed. Maybe an event handler that does not require a thread to
be sitting and waiting for events trying in a loop would be nice,
instead something that is triggered each time there is a certain event
class triggered. Also, there has been some interest in doing full
endpoint modules in mod_managed. exposing all the state handlers
in .net like ways and having that all work would be quite interesting,
but probably requires someone specific actually ready to write a
module like that to be worthwhile.
Mike
On Sep 24, 2009, at 4:01 AM, Michael Giagnocavo wrote:
Great – hopefully we’ll meet on IRC or the conference sometime on
Friday. Email me when you’re on.
A few questions I have:
Clarity – I agree with you there, and thanks!
Testability – is this even remotely practical? Looking at our FS
code plugins, there’s simply no way any amount of test environment
code would get us to anything testable. We make tons of direct P/
Invoke calls, and the whole model for what variables are set when,
the state machine progression, etc. does not seem like something
that we can hope to possibly model right. And it’s subject to many
external influences (all the modules you have loaded in FS). Logging
is a pretty simple case, sure, we can make it not call FS for
testing. But in a real app, it just seems that there are way too
many dependencies, no? Maybe others who have apps written can chime
in?
Modularity – I agree there are two parts. But, I think they are
pretty tightly coupled. The FS interface into unmanaged code is done
via unmanaged code and is really clear: App, Api, ApiBackground. The
other ways I can think of are FS-specific, such as XML binding
interface and so on. But those are things we should just add to the
mod_managed core and be done with. I’m thinking maybe we are talking
about different things? Can you provide some user stories that we
want to cover with a pluggable loader/executor/etc.? Thanks for
putting up with me!
-Michael
From: [email protected]
[mailto:[email protected]] On Behalf Of
Josh Rivers
Sent: Thursday, September 24, 2009 12:32 AM
To: [email protected]
Subject: Re: [Freeswitch-users] Subscribing to events in managed
C# / .NET
On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <[email protected]
> 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
_______________________________________________
FreeSWITCH-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-
users
http://www.freeswitch.org
_______________________________________________
FreeSWITCH-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
