Ship v2

[danbarua]

Runnning in production at $dayJob for some time now, seems stable enough.

[danbarua]

@pragmatrix since you seem to have eyes-on the code and attention for detail, I'd like to hold off on this for a short while in case you catch more bugs/typos that I've missed. (Btw: I've considered doing a re-write in F# to see how concise I can get this - I have looked at your IVR F# lib with interest but am not good enough with F# to write a lib in it yet!)

I'd like to pick up the release pace but I'd like to know where everyone else is with this lib. I suspect there are more people who have forked the code and are running a custom fork than there are running from the NuGet packages.

Everyone else:
@Anber @RobThree @EvolvingNetworks @m-jepson @mguerrieri @yojinjin @Eternal21 @senpark15 @dchristoffersen-vivint @derwasp @SHAliakbari @padmanabanravikumar

here is the plan going forwards:

Once v2 is tidied up and released, I'll look to pick up the release cadence a bit.

At my dayjob, we'll always be using the latest on the master branch, as available from the unstable MyGet feed. But we may not be leaning as heavily on the parts of the library that you are, so we may miss things that aren't covered by the unit tests, and I may not consider your use cases in the design.
I would like to set up some integration/acceptance tests that cover the Channels API but that is not a priority right now (pull-requests welcome!)

The goals with this library are two-fold:

1. Provide a low-level API around the EventSocket that makes the ESL a pleasant experience to work with (the EventSocket API) ie. Less code than the C API + Swig (and less ugly code!)
2. Provide a high-level API that abstracts away the plumbing and low-level boilerplate so you can focus on writing business logic in C# and not worry about the details. You can still access the low-level api via the Channel.Socket object.

re: the above

1. The EventSocket API has become settled and is reasonably stable, I am committed to not breaking this across major versions unless necessary (usually bugfixes)- you'll see notes in the Release Notes and Breaking Changes document. There's always a reason why we've chosen to break things, which is why v1 (and v2) have taken their time before going up on NuGet.
2. The Channels API is experimental and evolving, currently I am using this at work but I am welcome to any feedback that may influence the design - the goal is optimising for developer experience, hence developer input (from you) is essential. The Channels API can and most likely will break across minor and major versions until we arrive at a stable design. If you're happy to live on the edge and give feedback then please join in. I don't want to bloat the API with every use case imaginable - that's why you can always drop down to the low-level API if need be, but feedback is appreciated. Remember, the focus is 'getting stuff done'.

For now, use cases at the dayjob are driving the design of the library, if I can get more feedback then obviously the development pace will pick up and we can consider breaking the Channels API out into a separate library/nuget package that can evolve separately from the low-level API. I suspect most people are using the low-level API.

If you have forked the library and made your own changes, please let me know, what needs does it not satisfy for you? Have you had performance issues (we are optimising for developer productivity over performance, (hence Rx + Linq + GC pressure, you'll always get better performance out the ESL lib but we'll do our best.)? Was there too much magic under the hood that you did not understand or was not documented clearly? A lot of trial-and-error experimentation has gone into this lib and there is a lot that I could write up in a wiki for EventSocket developers whether they are on the .Net platform or not - just take a look at the comments inside each method implementation for explanations and links to the wiki in the XDOC comments. If you've found any quirks let's get it documented as it helps everyone else (and the ESL API is FULL of quirks.)

Lastly - if you need my attention quickly- ping me on twitter.com/danbarua and I'll get back to you asap, otherwise file an issue here and I can get back to you within 48hrs.

If you are online 9am-5pm GMT, ping me on twitter and jump in the Gitter chat room and you might be able to grab me for a real-time chat if you have complex issues that need troubleshooting. So far, it seems to be 70% FreeSwitch/config issues and 30% NEventSocket issues.

It seems that FreeSwitch developers are not a vocal bunch, and perhaps not as used to participating in OSS judging by the number of new GitHub accounts I see interacting with this repository.

TLDR: This is a library designed for developers, but it needs developer input to make it as good as it can be so please provide feedback rather than just forking and disappearing into the void! I'm listening.

[danbarua]

@dchristoffersen-vivint

Any feedback on this discussion?: https://www.linkedin.com/groups/1887969/1887969-6130765090569342979

It would be good to know if NES was not a good fit and why.. or if it is and no news is good news.

[pragmatrix]

First of all, thank you for NEventSocket and for trying hard to build a working community!

Regarding V2, don't hold it off. I work in iterations in several projects and so it may take some time to get back to you.

Anyway, here are the things I found in my initial evaluation of which you might consider including some ideas in V2 or V3 (please also consider that I'm completely new to FreeSwitch):

Channels and Sockets seemed conceptually intertwined.

Our project has the requirement to originate several calls per socket and then bridge / unbridge them. For example we originate a call at 0s, and while the first one is ringing another one at 5s+ and see which answers first, and so the "bridge" support APIs, which combines originate with the media switch, so far did not quite fit. For that I needed a) get a Channel directly from the result of the originate call pragmatrix@7444765 and a kind of a low-level bridge, which just switches the media I've found with uuid_bridge pragmatrix@5433ba8.

Handling multiple unrelated Channels on one EventSocket implies that the event filters need to be tightly managed by the socket, similar to that what it does with event subscriptions. For example, the originate call assumes that it receives the events for the new channel UUID, which only happens when no filter is currently active. To get this working, I hacked this here (pragmatrix@0504ea3) but realize now that a lot more work needs to be done in this area.

Audio playback APIs feel too restricted.

The playback application in FreeSwitch seems designed for blocking use and I somehow don't see their advantage yet. uuid_broadcast seems to be a better fit for a number of situations, though I don't yet know if it works when a channel is bridged.

Concurrency

I've had race conditions with NEventSocket while trying some unusual things, like processing multiple originate calls at the same time, or just calling into NEventSocket APIs from different threads at the same time, because my code was broken. I don't quite feel 100% safe here, but will track down these issues one by one as soon they will happen in code I consider production ready.

One thing that confused me were the different uses of gate in EventSocket.cs: https://github.com/danbarua/NEventSocket/blob/master/src/NEventSocket/Sockets/EventSocket.cs#L193 https://github.com/danbarua/NEventSocket/blob/master/src/NEventSocket/Sockets/EventSocket.cs#L472 and why some EventSocket variables are synchronized and others are not.

The PlayUntilCancelled API is quite scary to this regard https://github.com/danbarua/NEventSocket/blob/master/src/NEventSocket/Channels/BasicChannel.cs#L241, calling in in an IDisposable and knowing that uuid_break "somehow, somewhen" gets sent to FreeSwitch, makes this a bomb threat. I am exaggerating, but such details matter as soon the diverse situations an API is used and the usage numbers scale up a lot. An alternative would be a kind of IAsyncDisposable, or providing a separate Playback object that offers async cancellation method, or managing the playback state directly inside the Channel (like done with recording) and offering a separate asynchronous cancellation method that just sends uuid_break.

---

That's all from the top of my mind. I am now looking forward to the maturing of the new Channel API and like the idea to separate the projects, because it requires a precise definition of interfaces which then guarantees that the abstraction barrier between low-level code and channels is not weakened easily.

I will also try to align the changes in my branch with yours by posting a few issues as soon I have the time to do so.

[Eternal21]

I know I will be using your library in my project, since I evaluated it a few months back, but it won't happen for a few more months. I plan on running the nuget version.

[mguerrieri]

My requirement is to use your library in a .NET Core application. To that end, I have created my own .NET core library project, moved your code into it, and made the necessary modifications. This involves referencing the .NET Core-compatible Rx-Main library, defining the LIBLOG_PORTABLE constant for LIBLOG, and adding my own constant to #if-out certain non-CORE supported functionality, such as all references to [Serializable] and ISerializable, as well as a few other changes. It is working well so far, but the app is still in development and not tested under load as of yet. So my suggestion would be to add .NET Core support to the codebase.

Mark Guerrieri

http://www.jmbtech.net/ JMB Technology, LLC

215-431-4156

mguerrieri@jmbtech.net

From: Dan Barua [mailto:notifications@github.com]
Sent: Friday, June 17, 2016 6:00 PM
To: danbarua/NEventSocket NEventSocket@noreply.github.com
Cc: Mark Guerrieri mguerrieri@jmbtech.net; Mention mention@noreply.github.com
Subject: Re: [danbarua/NEventSocket] Ship v2 (#41)

@pragmatrix https://github.com/pragmatrix since you seem to have eyes-on the code and attention for detail, I'd like to hold off on this for a short while in case you catch more bugs/typos that I've missed. (Btw: I've considered doing a re-write in F# to see how concise I can get this - I have looked at your IVR F# lib with interest but am not good enough with F# to write a lib in it yet!)

I'd like to pick up the release pace but I'd like to know where everyone else is with this lib. I suspect there are more people who have forked the code and are running a custom fork than there are running from the NuGet packages.

Everyone else:
@Anber https://github.com/Anber @RobThree https://github.com/robthree @EvolvingNetworks https://github.com/evolvingnetworks @m-jepson https://github.com/m-jepson @mguerrieri https://github.com/mguerrieri @yojinjin https://github.com/yojinjin @Eternal21 https://github.com/Eternal21 @senpark15 https://github.com/senpark15 @dchristoffersen-vivint https://github.com/dchristoffersen-vivint @derwasp https://github.com/derwasp @SHAliakbari https://github.com/SHAliakbari @padmanabanravikumar https://github.com/padmanabanravikumar

here is the plan going forwards:

Once v2 is tidied up and released, I'll look to pick up the release cadence a bit.

At my dayjob, we'll always be using the latest on the master branch, as available from the unstable MyGet feed. But we may not be leaning as heavily on the parts of the library that you are, so we may miss things that aren't covered by the unit tests, and I may not consider your use cases in the design.
I would like to set up some integration/acceptance tests that cover the Channels API but that is not a priority right now (pull-requests welcome!)

The goals with this library are two-fold:

1.  Provide a low-level API around the EventSocket that makes the ESL a pleasant experience to work with (the EventSocket API) ie. Less code than the C API + Swig (and less ugly code!)
   

2.  Provide a high-level API that abstracts away the plumbing and low-level boilerplate so you can focus on writing business logic in C# and not worry about the details. You can still access the low-level api via the Channel.Socket object.
   

re: the above

1.  The EventSocket API has become settled and is reasonably stable, I am committed to not breaking this across major versions unless necessary (usually bugfixes)- you'll see notes in the Release Notes and Breaking Changes document. There's always a reason why we've chosen to break things, which is why v1 (and v2) have taken their time before going up on NuGet.
   

2.  The Channels API is experimental and evolving, currently I am using this at work but I am welcome to any feedback that may influence the design - the goal is optimising for developer experience, hence developer input (from you) is essential. The Channels API can and most likely will break across minor and major versions until we arrive at a stable design. If you're happy to live on the edge and give feedback then please join in. I don't want to bloat the API with every use case imaginable - that's why you can always drop down to the low-level API if need be, but feedback is appreciated. Remember, the focus is 'getting stuff done'.
   

For now, use cases at the dayjob are driving the design of the library, if I can get more feedback then obviously the development pace will pick up and we can consider breaking the Channels API out into a separate library/nuget package that can evolve separately from the low-level API. I suspect most people are using the low-level API.

If you have forked the library and made your own changes, please let me know, what needs does it not satisfy for you? Have you had performance issues (we are optimising for developer productivity over performance, (hence Rx + Linq + GC pressure, you'll always get better performance out the ESL lib but we'll do our best.)? Was there too much magic under the hood that you did not understand or was not documented clearly? A lot of trial-and-error experimentation has gone into this lib and there is a lot that I could write up in a wiki for EventSocket developers whether they are on the .Net platform or not - just take a look at the comments inside each method implementation for explanations and links to the wiki in the XDOC comments. If you've found any quirks let's get it documented as it helps everyone else (and the ESL API is FULL of quirks.)

Lastly - if you need my attention quickly- ping me on twitter.com/danbarua and I'll get back to you asap, otherwise file an issue here and I can get back to you within 48hrs.

If you are online 9am-5pm GMT, ping me on twitter and jump in the Gitter chat room and you might be able to grab me for a real-time chat if you have complex issues that need troubleshooting. So far, it seems to be 70% FreeSwitch/config issues and 30% NEventSocket issues.

It seems that FreeSwitch developers are not a vocal bunch, and perhaps not as used to participating in OSS judging by the number of new GitHub accounts I see interacting with this repository.

TLDR: This is a library designed for developers, but it needs developer input to make it as good as it can be so please provide feedback rather than just forking and disappearing into the void! I'm listening.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #41 (comment) , or mute the thread https://github.com/notifications/unsubscribe/AEGPVc5mq-N4rVa68og4aEQTwbSHlP6Zks5qMxj6gaJpZM4I2Rbm . https://github.com/notifications/beacon/AEGPVaPqAkFuoT1iU5EoQIwFVEnkv-lPks5qMxj6gaJpZM4I2Rbm.gif

[RobThree]

Visual Studio 2015 displays some warnings (7 currently) which might be worth removing / having another look at before going V2:

[danbarua]

Still ironing out gremlins/reliability issues in production with this. Getting there...

[danbarua]

Update: doubled traffic in production at $dayJob. Leave it soaking in for a week or two then push to NuGet.

[danbarua]

v.2.1.0 pushed to public NuGet