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 <[email protected]> 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:* [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 > >
_______________________________________________ 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
