Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

I'm brainstorming about how Media Center exposes SDKs for plugins.

All of Media Center is written in C++.  Plugin like input, output, encoder, remotes, Theater View, etc. are generally C++ interfaces exported from a dynamic library.

To make a plugin, all someone really needs is the definition of the interface which is a simple header file.  Here's an example:
http://jriver.com/DevZone/JREncoder.h

However, if an independent developer writes in C++, as soon as they want to do something mildly complex like load a URL to a string, parse XML, load a JPEG, etc., they'll be off searching for the code to allow this.  Often the code to do these tasks is more complex than the plugin itself.

When JRiver develops a plugin, we use our own toolset to do these tasks.  The savings in time and code are enormous.

I'm trying to figure out if it's worth trying to allow a third-party developer to hook into our C++ toolset.  This would allow them to make a plugin exactly the same as we would, and allow us to more easily share sample code.

I haven't quite figured out how this might look.  

Would it be reasonable to ask developers of plugins that use this model to share a public SVN repository for the plugins?  In other words, we'd force the plugins to be open-source?  Authors could accept donations, and use a license to prevent further copying of the code, but not charge for the plugins or prevent JRiver from compiling them.

This way, JRiver would be able to compile the plugins to accommodate interface changes in the core libraries, accommodate 64-bit, cross-platform, etc.

I'm not even sure if directing energy towards native C++ plugins is worthwhile, or if it's better to focus on more accessible things like the web service.

Advice welcome.

[Scolex]

I personally think you would be better served by focusing on things like the web service because of the rate that the tablet market is growing.
Not to mention that MC is already very feature packed and I struggle to think of what could be added.

[jgreen]

I think Matt's point is, we don't know what could be added until it gets added.  Since I don't know what an SDK is, I won't advise on how to configure one or manage its use. 

Regarding the open-source aspect, is that how it's done with other app platforms?  I think whatever is typical for the space ought to be your policy also, if you're going to do it.  OTOH, you've already had some experience with predatory plugins, and people asking you to change your software in order to make their plugins work as advertised, when they never will.  There are customer service issues here that might be a bit of a learning curve for the Minnipops. 

[Hendrik]

Personally i think you should pickup the idea brought to you in the last SDK related thread, and offer an SDK/API in a modern scripting language (Python), which would already come with all the basic tools that you mention there (and you can still augment it by exposing some of your things, too)

[MrHaugen]

I think this is a VERY good idea Matt. I assume this would probably allow users to develop plugins for Theater View as well? I understand that there are a need for Plugins in standard view, but you could potentially avoid so incredibly much work by allowing third party plugins in Theater view as well. A few examples: Spotify, Netflix, Hulu playback. Yes, the last two is already in place, but if a really good SDK was available, MC users might have created this a long time ago and you don't have to make changes on it often like you do today. Perhaps it would also be possible to create completely new view types for Theater View. This could be really huge if done right and the users find it easy to use. There are much services that are not yet in MC, and makes people very reliant on other apps as well. That is not great. A Media Center should possibly be the only app you need on a HTPC. Just think of the addition of automation. This could be a plugin, and it could introduce a whole new dimension to Theater View, standard view and the automatic household.

I agree that Web services are important as well, but I think the benefit from a much better plugin development speed and possibilities for the users would be far more important to MC today than web parts is. MC really lacks in this field today, when you compare to plugins for apps like XBMC.

I do not have enough programming language experience to say whether you should use C++ or something else.

I also support the open license idea, so you have more freedom to integrate good additions natively. Especially if projects are abandoned.

[Matt]

Personally i think you should pickup the idea brought to you in the last SDK related thread, and offer an SDK/API in a modern scripting language (Python), which would already come with all the basic tools that you mention there (and you can still augment it by exposing some of your things, too)

That's a little different discussion, although the two may intersect.

For core components like inputs, encoders, visualizations, etc. a scripting language probably doesn't work.  For example, could you use Python to offer decoding of some new audio format?

[Hendrik]

For example, could you use Python to offer decoding of some new audio format?

Probably could, but if its a good idea is another thing.
But would a new decoder need fancy APIs? Most likely it'll just forward calls into another decoding library.

Anyhow, trying to expose some very basic APIs of course doesn't hurt, but i wouldn't put too much effort into it, personally.

[Jaguu]

In my opinion, one of the reasons why MC never developed a very large 3rd party developer community are the very productive JRiver programmers (Matt & Co.) pouring out new features at the speed of light, and very often changing established features (at least in the past).

Large 3rd party communities usually grow, when the basic software does not change too much between very long development cycles. 3rd party developers need stable platforms and conditions, so they do not have to adapt continuously to evolving platforms.

One very bad example is Firefox which upset many 3rd party developers as they were forced to adapt to ever changing release numbers and conditions, so that very often the only change was a new release number. I think MC also belongs to this category, so personally I doubt that a large 3rd party community will develop around JRiver and MC.

So you may have to rethink whether such an investment is really worthwile. Very often it is more productive from the users point of view to beg Matt for some badly needed feature. 

[raldo]

In my opinion, one of the reasons why MC never developed a very large 3rd party developer community are the very productive JRiver programmers (Matt & Co.) pouring out new features at the speed of light, and very often changing established features (at least in the past).

Well, I think there are some other reasons for this:
o Many key SDK features missing.
o Many key GUI features missing. Menus integration, Theater View integration
o Availability: Python is significantly more simple to set up than compiled projects.

If JRiver provided the framework for donations/payments/licensing on behalf of the plugin developers, now that would be great...

What about the "gray areas" when you integrate plugins even more? One advantage of JRiver distancing itself from plugins (basically the way it is today) is that there is a well defined barrier between plugin and JRiver.

An example: Say someone decided that they would make a Spotify plugin for MC. The plugin would dynamically import playlists from Spotify and you could play these playlists from MC.

With the current SDK, JRiver could just lean back and say "it's not our responsibility, we provide an interface but we have no control over what users install".

What if there were a JRiver repository and jriver compiled the code? Gray area.

[gvanbrunt]

I don't know how well a closed source product requiring open source plug-ins would fly. There may be some in the open source community that would object loudly etc. As far as I know it's never really been done before. There is the legal aspects of it as well. There are a many Open Source Licensing varieties and the legalities are relatively well understood. This won't work with many of them, or if they do may have unseen legal complications. I'm not against it, just saying it's uncharted territory.

As for API's, I think scripting is well taken care of already. Between the available COM APIs, MCC Commands, and Web API you can script many functions with a variety of tools\languages. There are a few missing and it may be good idea to add them during polishing. One thing that is missing, is some updated Wiki examples of using various tools to accomplish common tasks. If the community could "make a list" of 20 common tasks, I'm sure there are more than a few of us that can create examples. I'm sure that would be really handy to all. Perhaps someone could start at thread?...

I agree with Jaguu in this:

o Many key SDK features missing.
o Many key GUI features missing. Menus integration, Theater View integration

That is the area that is lacking and I'm assuming they type of plug ins you are talking about. While C++ is very powerful, it is not a good tool to write them in for all the reasons you mentioned. It also has a very limited audience of developers today. I think trying to "hack something together" to make it work is ignoring the fact that it may not be the best tool for the job at hand. I would be much happier seeing one of the more common types of Plug Ins API's being supported. For example .Net, Java, etc. Personally I like .Net as it is language agnostic and can work via COM as well so you can use "anything you want to interface with it". If dev wants to use python, go ahead. Java? That's fine too. VB? Sure why not.

That said, if it is too much work, I would be happy to see the C++ headers. But I'm not sure how much it would get used... Personally I probably wouldn't have the time to develop using it....

[JimH]

I would be much happier seeing one of the more common types of Plug Ins API's being supported. For example .Net, Java, etc. Personally I like .Net as it is language agnostic and can work via COM as well...

The problem is that .Net isn't OS agnostic.  We'd like to be able to run MC on other OS's.

[gvanbrunt]

The problem is that .Net isn't OS agnostic.  We'd like to be able to run MC on other OS's.

I remember you mentioning this before. However given the amount of tie in MC has with the MS API's, I don't see how that is really feasible. For example direct show etc. I think porting to another OS would be a monumental undertaking to say the least. Then again, I'm not JRiver so I don't know the code...

However even if that were true, consider this:
All other media software I know of that runs on multiple OS's is ugly as sin and difficult to use. I won't mention names so as not to start a flame war. I think the reason for this is the many compromises you have to make to remain OS agnostic. It would be great if MC could do that, but I think you are giving up a lot to do so - like a decent API.  Also, since you would likely have to decouple directshow etc, what is the difference if you have to do it with the "plug in" API as well? And consider that many of these programs have varying features depending on what platform you run them on. Nothing is stopping you from excluding it from a build on another OS.

All of that is a moot point though. I can appreciate that you don't want to be tied to .Net or COM. However I think most plug in API's these days can be built as wrappers around the "main one". Many programs support a multitude of programming platforms. Unfortunately it has been quite a while since I've been programming so I'm not familiar with the tools used to do this. Anyone else familiar with anything?

[Matt]

I think there are several topics here.

Controlling / scripting the program

We cover this reasonably well between the web service, command line, windows messages, and COM interface.  I'm particularly keen on the web service since it works across a network, it's usable from basically every language, and it's easy to expand without breaking existing functionality.


Traditional plugins for DSP, visualizations, input formats, encoders, etc.

It sounds like most people are saying just releasing the C++ interfaces (which we already do) is sufficient.


New types of plugins

This is a possibility for the future.

I understand the argument that Python or .NET are easy to program and well documented, and this advantage shouldn't be underestimated.

However, I'm also not thrilled about core (often performance-critical) functionality being tied to a big framework, both for efficiency and portability reasons.

[glynor]

I might be a completely crazy person, but what about Perl?

It seems to fit quite nicely with the goals of expanding upon the capabilities of controlling/scripting the core application via the web service, and the already-powerful database and filtering engine underneath MC.  It is a modern language, avoiding many of the memory access problems of the C languages, and is still being actively developed and used widely.  And, despite the crazy Perl script done for show you might have seen, it can be quick to learn and use, especially with current Perl syntax.

And, of course, it is quite cross platform.  You can easily wrap Perl code into self-contained EXE files on Windows, and the framework is included on most flavors of Unix (including OSX and Linux).

I don't know.  I don't know Perl well at all either way, so I have no vested interest (if anything, I know the .NET stuff the best).  And, I don't know much about the .org governance other than that Larry Wall still has something to do with the development (but does he control it?)....  Either way, I think it might be worth considering.

PS.  Or maybe a real scripting language system like Lua?  But that seems like a whole big project, and I think it might have less power and more limited appeal.  Then again, so might Perl.  I don't know... C/C++ is moldy and creaking around the edges (and you already have it).  I don't like Java, or Oracle.  I agree with you about .NET.  Same thing and more for Objective C since MC doesn't even run there (and it is a little creaky).  Python is fairly cool, but it really isn't native anywhere without extra steps, has even more limited "curbside appeal" than Perl, and I think it doesn't perform super-well (but I'm probably talking out of my nether regions there as I haven't looked at it anytime near recently and I'm not a good programmer -- Don't email me).

[glynor]

I'd say the other things to consider might be web frameworks like Ruby or Javascript.  Javascript probably has the biggest install base of anything, but it is so horrible.  

Still, a Javascript front end to the existing web services might be.... Cross platform and powerful.  I don't know enough at all about web programming to know if what the web services system already has is sufficient in these areas, though.

[MrC]

Perl is a memory pig.  It trades space for time, and requires a large runtime engine (e.g. ActivePerl).  The memory bloat is about 20x what a straight C implementation might be.  While some of the language constructs would be very useful in the expression context, it would have little use in MC otherwise.

btw. the squeezebox team after years with an all-Perl server finally realized to gain performance, they had to move the scanner and other portions of the server to C.  And while they enjoy the benefits of many perl modules, they also suffer the downside of constant updates, errors, and some dependency hell.

[Hendrik]

I might be a completely crazy person, but what about Perl?

In case you're still wondering, yes you are.

[MrHaugen]

Yes. I always imagined Glynor in a locked down place with men in white coats. I have wondered many times how he's able to write on this forum with a straitjacket though. Not to mention the fact that he have Internet access....

[gvanbrunt]

We cover this reasonably well between the web service, command line, windows messages, and COM interface.  I'm particularly keen on the web service since it works across a network, it's usable from basically every language, and it's easy to expand without breaking existing functionality.

Yes I would agree there. There are also plenty of tools for dealing with with XML and REST types in most scripting languages. As mentioned though, there are some requests I've seen that still need to be filled - can't remember them off hand though. And I think the List of 20 common Operations in various lang would allow many more to take advantage of it. Those besides us with lots of scripting experience. I am going to start a thread on the main board about that...

Traditional plugins for DSP, visualizations, input formats, encoders, etc.

It sounds like most people are saying just releasing the C++ interfaces (which we already do) is sufficient.

I agree.

However, I'm also not thrilled about core (often performance-critical) functionality being tied to a big framework, both for efficiency and portability reasons.

Was just thinking that last night. I can start MC into Theater View from the command line in under a couple of seconds on mediocre hardware. That is quite and accomplishment. However, if the API can be added without impacting performance, I would say to go ahead and do it, but warn people that using plug-ins may slow things down. Maybe make it off by default and has to be enabled via Options. From my perspective, if it boiled down to slightly slower performance vs missing features that I can't live without, I would take the hit gladly. I think the key here is testing. If adding the API can be done without significant performance impact, and the slow down only occurs when plugs ins are used, then go for it.

If that can't be done, surely there must be some framework that has decent performance and a high level lang with good tools and modules?

[nwboater]

I have nothing to contribute from a technical perspective, but want to thank you for trying to find ways to be able to expand the add-on developer community. My experience with SageTV has shown that a motivated group with the proper tools can accomplish wonderful things that we can all benefit from.

Good luck.

Rod

[glynor]

Perl is a memory pig.  It trades space for time, and requires a large runtime engine (e.g. ActivePerl).  The memory bloat is about 20x what a straight C implementation might be.  While some of the language constructs would be very useful in the expression context, it would have little use in MC otherwise.

Like I said, I don't have a horse in the race for this really, and I do not disagree with any of those criticisms versus C in a general sense (though modern Perl is not about the crazy people with the shortest-program-ever code anymore at all).  But I was responding to Matt here:

Traditional plugins for DSP, visualizations, input formats, encoders, etc.

It sounds like most people are saying just releasing the C++ interfaces (which we already do) is sufficient.

New types of plugins

This is a possibility for the future.

I understand the argument that Python or .NET are easy to program and well documented, and this advantage shouldn't be underestimated.

However, I'm also not thrilled about core (often performance-critical) functionality being tied to a big framework, both for efficiency and portability reasons.

And, besides, comparing to the performance characteristics of C wasn't my point.  They already have a C++ interface.  I don't think there was ever any discussion about replacing this or changing the code-base of MC itself!  He was talking about enhancing it, in fact, asking about giving access to the internal JRiver toolset in some way (which I think, if done well, could be very powerful).  But the discussion moved on to other potential new types of plugins, which Matt said could be a possibility.  A new, second type of framework for MC.

Those same arguments you gave against Perl would apply to almost any modern protected-memory, interpreted, high-level language, to some degree or another, except specialty ones and those around the fringes (where you trade exposure possibilities for elegance and then what's the point?).  Now, I can't authoritatively argue that Perl isn't comparatively much, much worse than Python, or Lua, or .NET, or Java, or insert-your-pet-language at all.  I'm a decidedly uneducated programmer, and a hobbyist.  I've done quite a few projects in C#, a little Perl, a little Java, and I did a whole bunch more as a kid in old versions of BASIC and then VB (and by VB6 I was actually writing object-oriented code that wasn't horrible VB hack-jobs and had some elegance).  I've studied C and C++, but if you're getting into it late, as a hobby, with a full-time-job, that really feels like looking at the past...*

And memory is cheap.
Darn cheap.  Who cares.  Drop a massive $24 and buy yourself another 4GB of RAM if you're limited and you want to run a little widget here and there.  Compared to the massive bloat everywhere else in your browser and on the website you visit and in Flash are we splitting hairs?

All I was saying is that, as a possible addition, it seems like that for "one of those kinds of interpreted languages" Perl does not have some of the negatives associated with those other alternatives I listed, and might be worth considering.  If you're going for that kind-of system, it does have some things going for it, despite a somewhat tarnished name.

And, even then, that's only if it makes sense to go with any kind of "traditional" or "semi-traditional" second programming interface.  As I mentioned, putting more efforts into building out the web-framework-based API also really seems like it should get a lot of consideration as well.

* I should add...Not if you plan to develop professionally or for anything where performance really matters.  Then, obviously, I agree C/C++ is still usually the best choice, unless inherant cross platform support is a core design goal.  But I think Matt's goal was to make it more accessible to hobbyist, non-professional expert users, who do have programming experience, but aren't pro programmers working in their spare time.  People like us on the beta team.  The endgame is to try to expand the number and capabilities or the plugins (the MC ecosystem, to use a weasely phrase).

And I agree that Perl is not without substantial issues of its own.  Do you support Perl 5 or 6 now, for example?  I don't think any of the options are a slam dunk.

[glynor]

In case you're still wondering, yes you are.

Yes. I always imagined Glynor in a locked down place with men in white coats. I have wondered many times how he's able to write on this forum with a straitjacket though. Not to mention the fact that he have Internet access....

 

After this week, I sure feel like it.

Children are lucky they are so adorable, because they are steaming cesspools of disease.  Also, I was almost certainly still a bit delirious when I wrote my original "consider Perl" quip.

[Listener]

After this week, I sure feel like it.

Children are lucky they are so adorable, because they are steaming cesspools of disease.  Also, I was almost certainly still a bit delirious when I wrote my original "consider Perl" quip.

I'd take a season of colds over a permanent Perl infection.

Bill

[gvanbrunt]

But I think Matt's goal was to make it more accessible to hobbyist, non-professional expert users

I think you nailed it there. Not many of them know C or C++. If that is the intent, I don't think it will get used much. Unless there was access to JRiver "tool kit" and to really good code examples. Then it might work.

[MrC]

I'm not so sure how long before ones runs into the point of diminishing returns.  Language experts have been trying for years.  The dumber the language, the more complex the required solution.  The existing MC language is already overwhelming to almost all users.  Any of the existing scripting languages are complex well beyond that.

The scripting language's primary goal should be to provide the desired functionality first and foremost.  The audience will have to familiarize themselves with the language.

[Matt]

Bump.

This was a brainstorming discussion we had in the beta board a while back, but I thought it might be generally interesting.

[brendonp]

Ok, it seems I'm jumping into the fray - I'd posted up some thoughts yesterday here http://yabb.jriver.com/interact/index.php?action=post;topic=74981.0. but this may be a more appropriate place.

Jaguu makes a good point about a static API; however this should be achievable by abstracting the API from direct function calls within JRiver - ie, a simple facade pattern.   It does put pressure on the JRiver devs to create & maintain the facade, adding features as necessary without deprecating calls used by plugins.

I think Jim and/or Matt had also mentioned something about .NET being a potential dead end to maintain platform independence, though you could probably look at the MONO project to help out a bit (I've used it for web stuff with some success).   I would assume that the user base is predominantly MS based, so it might also be worthwhile generating a static API /w the facade mentioned above along with a couple of wrappers for .NET or other languages... I'm not a big fan as it means that some plugins might only function with certainly OSes, but you might wind up jumpstarting development.

The other route, as mentioned in the thread linked above would be to offload some of the online media plugins to an online server based system.  ie, online media is "browsed" through web pages or other markup that works with JRiver themes (I'm thinking mainly of TheatreView here), and the plugins become server based.   Naturally you're then dealing with having scalable a hosted site available and the costs involved - perhaps a separate revenue stream?

However, ultimately this decision would probably have to come down from the JRiver team as it goes directly to their business model.

My $.02 for now...

[Matt]

Let me show an example of how the actual code is often trivial.

A while back, Glynor said "Hey, you should let me read The Verge from Theater View > News."

We added it.  Here's the complete code:

Code: [Select]

class CTheVergeRSSReaderSite : public CNewsReaderSite
{
public:
CTheVergeRSSReaderSite();
virtual ~CTheVergeRSSReaderSite();

virtual void GetDivs(JRStringArray & aryIncludedDivs, JRStringArray & aryExcludedDivs);
};

CTheVergeRSSReaderSite::CTheVergeRSSReaderSite() :
CNewsReaderSite(_T("The Verge"), _T("http://www.theverge.com/rss/index.xml"))
{
}

CTheVergeRSSReaderSite::~CTheVergeRSSReaderSite()
{
}

void CTheVergeRSSReaderSite::GetDivs(JRStringArray & aryIncludedDivs, JRStringArray & aryExcludedDivs)
{
aryIncludedDivs.Add(_T("article-body"));
}


So for a case this simple, it could just be a little XML file telling the program what to do.  But this falls down as soon as you want to do a somewhat-complex thing.

I'm still keen on the idea of C++ code compiled at run time (a little scary for security), or an SVN branch for some sorts of plugins run by JRiver that gets compiled into the build (a little tricky if a developer wants to sell an add-on).

[MrHaugen]

I'm still keen on the idea of C++ code compiled at run time (a little scary for security), or an SVN branch for some sorts of plugins run by JRiver that gets compiled into the build (a little tricky if a developer wants to sell an add-on).

I do not know how things really could work in the core here, so I will not and can not give suggestions as how to compile it or what language to use. I'd just like to point out the way for instance XBMC handles plugins. You simply browse to the appropriate plugin with your remote, select it and it downloads and installs. There is also the possibility of simple configuration of each plugin within the "theater view". This is what I call a good starting point for managing such plugins. I think this would be difficult if plugins was to be compiled and baked into every build. MC size would grow rapidly, and it would become too much work for you guys to add every little plugin.

[brendonp]

Let me show an example of how the actual code is often trivial.

A while back, Glynor said "Hey, you should let me read The Verge from Theater View > News."

We added it.  Here's the complete code:

Matt - in this case, it appears that we're dealing with very common data - namely RSS.    It may be the case that several plugin templates are required - ie, an RSS Template for news and textual data, perhaps another template for oEmbed enabled data (ie, Hulu, Youtube, Flickr, etc)....

As developers there's always the quest for the holy grail of unified interfaces, but anytime the project has a wide range of data sources (for which we can't dictate format), it becomes much more difficult to abstract away enough from singular sources while maintaining some sort of ease-of-use for the end developers.   Since, in this case, the end developers are likely to be unpaid third parties (at least in the near term), ease of use may be the more important criteria...

Again, just my $.02...