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

Sat Sep 26 17:18:22 PDT 2009

I don't know what we'd want to write endpoints for, so I'll leave that one
alone... ;)
I do, however, agree with you on the event handler idea. My work on the
module system is largely a precursor to putting in some work on a pub/sub
event bus in managed code. I wanted some lifecycle and exception handling
control that wasn't easy in the existing dll and I wanted to be able to
create it without breaking stuff for other people.

My question is this: is an event bus a good thing to put in mod_managed, or
should it be an optional plugin that you load in?

Josh

On Thu, Sep 24, 2009 at 9:26 PM, Michael Jerris <mike at jerris.com> wrote:

> 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:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Josh Rivers
> *Sent:* Thursday, September 24, 2009 12:32 AM
> *To:* freeswitch-users at lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Subscribing to events in managed C# /
> .NET
>
>
>
> 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
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> 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
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090926/abed18ee/attachment-0002.html 