<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://2108/">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is a new function I checked in a little bit ago that lets
you create any of the SWIGTYPE_p_xxx types – all you need is a pointer to the
memory to represent whatever it is in native land. So with that, it’s actually
possible to call most or all of the functions. (Yes DRK, you can now go do XML
binding.) But sure, it’d be nice to make a real .NET-ish layer. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Async events seems like it wouldn’t be hard, assuming FreeSWITCH
delivers them that way?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Michael<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
freeswitch-users-bounces@lists.freeswitch.org
[mailto:freeswitch-users-bounces@lists.freeswitch.org] <b>On Behalf Of </b>Michael
Jerris<br>
<b>Sent:</b> Thursday, September 24, 2009 10:26 PM<br>
<b>To:</b> freeswitch-users@lists.freeswitch.org<br>
<b>Subject:</b> Re: [Freeswitch-users] Subscribing to events in managed C# /
.NET<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>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.<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Mike<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On Sep 24, 2009, at 4:01 AM, Michael Giagnocavo wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Great – hopefully we’ll meet on IRC or the conference sometime
on Friday. Email me when you’re on.</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A few questions I have:</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Clarity – I agree with you there, and thanks!</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Michael</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>
</div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>
<div>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> </span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><a
href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a><span
class=apple-converted-space> </span>[mailto:freeswitch-users-bounces@lists.freeswitch.org]<span
class=apple-converted-space> </span><b>On Behalf Of<span
class=apple-converted-space> </span></b>Josh Rivers<br>
<b>Sent:</b><span class=apple-converted-space> </span>Thursday, September
24, 2009 12:32 AM<br>
<b>To:</b><span class=apple-converted-space> </span><a
href="mailto:freeswitch-users@lists.freeswitch.org">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b><span class=apple-converted-space> </span>Re:
[Freeswitch-users] Subscribing to events in managed C# / .NET</span><o:p></o:p></p>
</div>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p>
<div>
<div>
<p class=MsoNormal>On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <<a
href="mailto:mgg@giagnocavo.net">mgg@giagnocavo.net</a>> wrote:<o:p></o:p></p>
</div>
<div>
<div>
<p><span class=apple-style-span><span style='font-size:11.5pt;color:#1F497D'>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><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>My refactoring had the following goals (in no particular
order)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> - 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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> - 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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> - Modularity - I wanted to make it easy to remove or
add alternative behavior to the managed.dll.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span class=apple-style-span><span style='font-size:11.5pt;color:#1F497D'>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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal>I completely agree, with the following caveats:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>2) I'd like to allow folk to make changes to the default
behavior (optimally) without recompiling managed.dll.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> 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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal>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 :)<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>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 class=apple-converted-space> </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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>(BTW, I think WCF-Mono is getting there <a
href="http://www.mono-project.com/WCF_Development">http://www.mono-project.com/WCF_Development</a>)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>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><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal>I'd be very glad to get a discussion going. I definitely
haven't covered all of the issues here.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal>-Josh<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'>_______________________________________________<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">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>
<a href="http://www.freeswitch.org">http://www.freeswitch.org</a><o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>