WTF
Mono.Upnp is a fully managed UPnP implementation. The client and server stacks are in separate libraries to give embedded devices a compact solution for either. The client library is a solid implementation of the UPnP standard designed to robustly cope with other, less compliant UPnP devices (seriously, no one actually implements the UPnP standard correctly. Especially not router manufacturers, may they die a thousand deaths). The client API is also highly extensible, allowing easy consumption of services which offer functionality not established in the spec. The server library offers developers an easy way to expose their services over UPnP: attributes indicate UPnP-visible members and the library handles all of the network plumbing. In addition, all of the official UPnP device and service APIs (the specs which sit on top of the UPnP architecture - for example, the MediaServer API) are wrapped both for client and server use.
Holy Shit!
Indeed. Well, almost. All of the above sounds great, but it's not done yet. In fact, it's still quite experimental. While I've made great progress in impressive screenshots, actually listening to your Banshee collection on a PS3 is still a few hack-o-thons off. But things are moving along nicely and I will certainly keep you up to date.
OK
In the mean time, curious monkeys can find the source in the mono-upnp module of the Mono SVN. Like I said, you shouldn't be using this code, but you're welcome to check it out.
11 comments:
I'll investigate porting Mono.NAT over to use Mono.UPnp for upnp router support when you deem the API stable enough for me to consume. Keep me posted ;)
This is basically amazing... I've been poking around a bit lately in upnp stuff, mostly because I am fed up with having no decent upnp solution for my HTPC running MediaPortal...
Keep it up, this has got me excited!
Nice work but may I ask what was wrong with GUPnP? I thought Aaron and I had an understanding that GUPnP is the way to go.
There is nothing wrong with GUPnP per se, it is just not an ideal solution for our (Banshee's and my) purpose because it is a unmanaged dependency. The advantage of a fully managed library is that it works out of the box on all systems with Mono or .NET. And it provides a more familiar API for CLI/C# developers.
There is nothing wrong with GUPnP per se, it is just not an ideal solution for our (Banshee's and my) purpose because it is a unmanaged dependency.
What do you mean by "unmanaged"?
the advantage of a fully managed library is that it works out of the box on all systems with Mono or .NET.
Doesn't Banshee uses gstreamer? If gstreamer can be ported to all platforms, I am sure porting GUPnP shouldn't be an issue (if not trivial).
And it provides a more familiar API for CLI/C# developers.
Of course, we need C# bindings (amongst other languages/platforms) but a few developers alone can't do it all so contribution is always welcome. Now with gobject introspection coming into shape, I think this is soon going to be a non-issue for most of the GNOME libraries.
The thing is that if Banshee really wants to be a GNOME app, it should go for libraries that work for everyone not just C#/.NET lovers. Elisa uses Coherence and now you are doing your own stack so we'll end-up with at least 3 different UPnP stacks in GNOME and we only need one.
What do you mean by "unmanaged"?
http://en.wikipedia.org/wiki/Managed_code
Doesn't Banshee uses gstreamer?
Real time A/V decoding is integral to Banshee's functionality and we could not accomplish it with a virtual machine even if we were inclined to write a media decoding stack. UPnP is something we'd like to have and it is relatively easy to write and maintain (the UPnP spec isn't going to change).
The thing is that if Banshee really wants to be a GNOME app, it should go for libraries that work for everyone not just C#/.NET lovers.
I think we have different definitions of "everyone." You take it mean everyone on the GNOME desktop. I take it to mean everyone on a platform with the ECMA-335 2.0 virtual machine. Your subset is GNOME users. My subset is a lot of Linux users, some BSD users, some Solaris users, a few Mac users, and almost everyone on Windows.
It is also worth noting that while Mono.Upnp will be used by Banshee, it is a separate project.
I am sensitive to your concerns about code duplication but I believe the benefits justify the costs.
As Scott says, the advantage of mono-upnp is that it is not bound to Linux/Gnome, and it can go with very little effort to where no other software has gone.
It will help make UPnP easier to consume and produce not only for Linux users, but will help spread this to users on the Windows, MacOS and other Unixes world with no external dependencies.
Historically, unmanaged dependencies have become a burden and many Mono-based projects are trying to eliminate them from their projects.
Managed code is easier to develop, maintain, reuse, extend and debug.
Hi Scott,
I have a lot of experience writing Upnp stacks, both in C#, and C++. Quite apart from anything else I might be able to help you with any problems you encounter with your Upnp developments. If you want to get in touch, please email me (graham.darnell@linn.co.uk)
Best regards
Graham
ps OSS site at http://oss.linn.co.uk
Its hard to find out something about Mono.Upnp, since I dont know who I should mail to I can only leave a comment here.
In Ssdp socket on Line 49/50 the Socket is Bound to interface 0, which is a horrible Idea... It took me half a day to figure out why not even Wireshark got a packet, because it got sent to the wrong interface...
Leave that line completly and let the OS decide which Interface should be used!
Maybe you wouldn't mind watching the language on your site. I was hoping to use mono.upnp for a school project... but I don't feel comfortable sending kids here. WTF, etc... are totally unnecessary words for people who cannot express themselves will.
The language comment is fair. I'll take it under consideration. The code itself should be profanity-free, so please feel free to contact me if I can be of any assistance to your curriculum. Truth be told, nothing flatters a software engineer more than to have their code taught :)
Post a Comment