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

[Michael Jerris]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090925/8948c710/attachment-0002.html