I don't know what we'd want to write endpoints for, so I'll leave that one alone... ;)<div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Josh<br><br><div class="gmail_quote">On Thu, Sep 24, 2009 at 9:26 PM, Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com">mike@jerris.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">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.<div>
<br></div><div>Mike</div><div><br><div><div><div></div><div class="h5"><div>On Sep 24, 2009, at 4:01 AM, Michael Giagnocavo wrote:</div><br></div></div><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div lang="EN-US" link="blue" vlink="purple">
<div><div></div><div class="h5"><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">Great – hopefully we’ll meet on IRC or the conference sometime on Friday. Email me when you’re on.</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">A few questions I have:</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">Clarity – I agree with you there, and thanks!</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">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?</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">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!</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">-Michael</span></div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"> </span></div>
<div style="border-right-style:none;border-bottom-style:none;border-left-style:none;border-width:initial;border-color:initial;border-top-style:solid;border-top-color:rgb(181, 196, 223);border-top-width:1pt;padding-top:3pt;padding-right:0in;padding-bottom:0in;padding-left:0in">
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"><b><span style="font-size:10pt;font-family:Tahoma, sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma, sans-serif"><span> </span><a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" style="color:blue;text-decoration:underline" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><span> </span>[mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>]<span> </span><b>On Behalf Of<span> </span></b>Josh Rivers<br>
<b>Sent:</b><span> </span>Thursday, September 24, 2009 12:32 AM<br><b>To:</b><span> </span><a href="mailto:freeswitch-users@lists.freeswitch.org" style="color:blue;text-decoration:underline" target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b><span> </span>Re: [Freeswitch-users] Subscribing to events in managed C# / .NET</span></div></div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
</div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:12pt"> </p><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <<a href="mailto:mgg@giagnocavo.net" style="color:blue;text-decoration:underline" target="_blank">mgg@giagnocavo.net</a>> wrote:</div><div><div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif">
<span><span style="font-size:11.5pt;color:rgb(31, 73, 125)">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.</span></span></p>
</div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">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.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> </div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
My refactoring had the following goals (in no particular order)</div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
- 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.</div></div><div>
<div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> - 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.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> - Modularity - I wanted to make it easy to remove or add alternative behavior to the managed.dll.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> </div></div><blockquote style="border-top-style:none;border-right-style:none;border-bottom-style:none;border-width:initial;border-color:initial;border-left-style:solid;border-left-color:rgb(204, 204, 204);border-left-width:1pt;padding-top:0in;padding-right:0in;padding-bottom:0in;padding-left:6pt;margin-left:4.8pt;margin-right:0in">
<div><div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif"><span><span style="font-size:11.5pt;color:rgb(31, 73, 125)">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.</span></span></p>
</div></div></blockquote><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">I completely agree, with the following caveats:</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">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.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">2) I'd like to allow folk to make changes to the default behavior (optimally) without recompiling managed.dll.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> </div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
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.</div>
</div><blockquote style="border-top-style:none;border-right-style:none;border-bottom-style:none;border-width:initial;border-color:initial;border-left-style:solid;border-left-color:rgb(204, 204, 204);border-left-width:1pt;padding-top:0in;padding-right:0in;padding-bottom:0in;padding-left:6pt;margin-left:4.8pt;margin-right:0in">
<div><div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif"><span style="font-size:11pt;color:rgb(31, 73, 125)"> 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.</span></p>
</div></div></blockquote><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">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 :)</div>
</div><blockquote style="border-top-style:none;border-right-style:none;border-bottom-style:none;border-width:initial;border-color:initial;border-left-style:solid;border-left-color:rgb(204, 204, 204);border-left-width:1pt;padding-top:0in;padding-right:0in;padding-bottom:0in;padding-left:6pt;margin-left:4.8pt;margin-right:0in">
<div><div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif"><span style="font-size:11pt;color:rgb(31, 73, 125)">Things like making a published SOAP interface for FS seem not really related to mod_managed. They can easily be done as 3<sup>rd</sup><span> </span>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.</span></p>
</div></div></blockquote><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">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.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">(BTW, I think WCF-Mono is getting there <a href="http://www.mono-project.com/WCF_Development" style="color:blue;text-decoration:underline" target="_blank">http://www.mono-project.com/WCF_Development</a>)</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">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.</div>
</div><blockquote style="border-top-style:none;border-right-style:none;border-bottom-style:none;border-width:initial;border-color:initial;border-left-style:solid;border-left-color:rgb(204, 204, 204);border-left-width:1pt;padding-top:0in;padding-right:0in;padding-bottom:0in;padding-left:6pt;margin-left:4.8pt;margin-right:0in">
<div><div><p style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif"><span style="font-size:11pt;color:rgb(31, 73, 125)">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.</span></p>
</div></div></blockquote><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">I'd be very glad to get a discussion going. I definitely haven't covered all of the issues here.</div>
</div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> </div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt">
-Josh</div></div><div><div style="margin-right:0in;margin-left:0in;font-size:12pt;font-family:'Times New Roman', serif;margin-top:0in;margin-bottom:0.0001pt"> </div></div></div></div></div></div><div class="im">_______________________________________________<br>
FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org" style="color:blue;text-decoration:underline" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" style="color:blue;text-decoration:underline" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br><a href="http://www.freeswitch.org" style="color:blue;text-decoration:underline" target="_blank">http://www.freeswitch.org</a><br>
</div></div></span></blockquote></div><br></div></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>