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

[Josh Rivers]

Where does 'somePtr' come from?

On Sun, Sep 27, 2009 at 4:06 PM, Michael Giagnocavo <mgg at giagnocavo.net>wrote:

>  It’s in the “FSUtil” class (no I’m not happy with the name). I also made
> it an extension method on IntPtr (I’m not a big fan of extension methods,
> but the code is sorta messy anyways, so it’s not relatively bad.)
>
>
>
> var x = CreateSwigTypePointer<SWIGTYPE_p_int>(somePtr);
>
>
>
> Moving stuff out of the SWIG DLL removes the ability to use partial classes
> to extend the generated swigtypes. This is used a bit, and will be used a
> lot more as the managed plugin is cleaned up. For example, most of the FS
> APIs return string, when they should return a better representation. Also,
> the constructors for some of the types are internal only, and I don’t really
> enjoy using reflection to create them.
>
>
>
> -Michael
>
>
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Josh Rivers
> *Sent:* Saturday, September 26, 2009 11:29 PM
>
> *To:* freeswitch-users at lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Subscribing to events in managed C# /
> .NET
>
>
>
> The ability to directly create swigtypes...that's huge! I'd love to see
> some examples of how to use that.
>
>
>
> I've update my refactoring to include the changes to the trunk up through
> r14981. I've also checked in updated binaries that should work with the
> latest trunk builds(I hope?)
>
>
>
> A question occurred to me: would it make any sense to push the plugin
> loader into a separate DLL? That way we could keep the P/Invoke layer very
> cleanly separated from the loader/process host/abstraction layer structures.
>
>
>
> Josh
>
> On Fri, Sep 25, 2009 at 1:13 PM, Michael Giagnocavo <mgg at giagnocavo.net>
> wrote:
>
> 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.
>
>
>
> Async events seems like it wouldn’t be hard, assuming FreeSWITCH delivers
> them that way?
>
>
>
> -Michael
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Michael
> Jerris
> *Sent:* Thursday, September 24, 2009 10:26 PM
>
>
> *To:* freeswitch-users at lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Subscribing to events in managed C# /
> .NET
>
>
>
> 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
>
>
>
> _______________________________________________
> 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/20090927/4eec6194/attachment-0002.html