MPAnywhere - a proof of concept for an MP2 webservice and webinterface (2 Viewers)

[FreakyJ]

Sorry for spaming this thread, but I'm really interested in this topic

I'm really not good at designing some stuff, but I googled a bit and found this three layouts:
http://www.sonicwall.com/us/shared/image/screenshot_AI_app-flow-monitor_1.jpg
http://www.administrator.de/images/content/6d81df4adec86f7365cf3f34c782c5a0.jpg
https://server.nitrado.net/img.nitrado/games/template/webinterface-gameswichting-all_deu.png
(this is also the order of my preference) What do you say?

Or can @ncoH or @joostzilla come with a good design idea?

 

[Valk]

(I haven't had a proper look yet)
If it's done as an MVC site you can template to suit. That way we can try out many designs relatively easily.

Hopefully though someone might come up with an awesome (animated, single page?) design we can use

 

[tomtom21000]

Hi everybody,



Currently, the menu entries are hard coded. But the idea is that the MPAnywhereService provides the menu tree dynamically via a webservice. This also makes clear what the RegisterMenuItem and UnregisterMenuItem methods are for. Other MP2 plugins can register menu items which will then automatically be provided via the webservice and displayed automatically in the menu tree. The parameters of these methods are just first ideas. I'm not yet happy with them, since I still need to think about how to store the tree in the server.

The menuPath parameter says where in the menu tree this menu items shall be displayed. The menuText is the text that is displayed in the menu at the given path.


cheers,

Michael

Michael,

I am no programmer, so I certainly have not a very deep understanding of things.

The part about the menu sounds like a duplicate action:

Plugins register menu item for MP2
in the future they should register them also for the webservice?

Wouldn't it be easier to register all menuitems automatically also for the webservice or query the existing menuitem from the according module?

tomtom

 

[Valk]

I'm not sure how far you can use the plugin.xml file that comes with every plugin for MP2 but with the service registration (and I guess menu) couldn't that information be pulled from the plugin.xml.

That way the hosting URI, menu items required (maybe more than 1), etc. could also be configurable if say a conflict occurs (even a UI could be made to easily... tweak the settings).

All that said I think your plugin must bind to *:{port} and all other plugins must supply a path but all still run on the same port. When someone browses the default page maybe have an error prompt if a conflict occurred.

If the information is pulled from a plugin file the loading order shouldn't matter so much as long as you can be notified once all plugins are loaded.

The other good part about using plugin.xml is the project wouldn't (I think) require any special treatment to work with MP2 or IIS, etc. short of an xml file.

 

[FreakyJ]

I already played a bit with it
Nothing big, but I wanted to have a look on it
I thought it would be a nice idea to have some important serverstats in the header and maybe some actions like restart etc. Will play a bit more with the layout this evening

But another important point: How do we deal with localization? In the past I often used a template system in php, so you have vars like {my_var} which is replaced by the templatesystem, but any idea how to do it here? So that we can have the webinterface in german, english, ... I think we shoudl plan this right from the beginning otherwise it would be a huge workload to change everything again...

 

[infinite.loop]

Very interesting project you started here.

So if I understand you right, the user basically has "MP2 in his browser", right?

If it is possible to get that working on any device (that supports HTML5) then this would be an VERY huge leap for MP as a product compared to all the other HTPC software!
No more need to create an app for every device / OS.

Yet the interface/gui is what will need a lot of attention. When you look at the app's available on i.e. iOS, then a "tree" will not quite cut it.

What I mean is that there might should be 2 ways to access MP through the web.
One that is more basic/admin'ish (i.e. to change configuration of a client/server? that would be pretty sweet ), and one (the default) that is fancy and eye-catching like:

yet the question is, where are the limits of HTML5? Can you do such with it?
Can you do "remote control"? etc.

But there are html5 game engines, so I guess a lot is possible today?

 

[MJGraf]

maybe we could batch it? so that we have a separator in the URI? e.g

Not sure if that works - my current understanding is that you need an APIController method on the server that takes as many parameters as you supply via the query part of the URI (maybe plus the ID, which we supply as part of the URI path in my example above. I don't know whether we can have a generic APIController that e.g. takes key-value pairs of strings or something like that. But I'll clarify this.

Is there a size limit for urls?

According to this there is no length limit imposed by the standard - but browsers seem not to accept the URIs as of a certain length (seems to be 2048 characters or maybe 4096 characters on some browsers). So this would probably not work taking into account that pictures are likely to be larger than 2kb.

I'm really not good at designing some stuff, but I googled a bit and found this three layouts: http://www.sonicwall.com/us/shared/image/screenshot_AI_app-flow-monitor_1.jpg http://www.administrator.de/images/content/6d81df4adec86f7365cf3f34c782c5a0.jpg https://server.nitrado.net/img.nitrado/games/template/webinterface-gameswichting-all_deu.png (this is also the order of my preference) What do you say?

These are looking great - but the general design is the same as the current MPAnywhere design: A top bar with some information, a menu on the left and a main panel in the center. The only thing that is different is "the pictures", i.e. how the treeview on the left looks, what the colours are, etc. This can easily be changed in extjs via "Themes". I chose the "Accessibility" theme for now, but you can easily change it to one of the other freely available themes by just adding one css file, changing the reference in index.html to that other css-file and add the necessary pictures folder. Have a look at the sencha extjs kitchen sink (see here). In the top right corner you can change the theme. I think over the weekend I even found a "theme designer" somewhere that you can use to make your own theme. So themes are a bit like skins in MP(2). That's supported natively in extjs - we could also quite easily add a combo box like in sencha's kitchen sink to change themes at runtime...

If it's done as an MVC site you can template to suit. That way we can try out many designs relatively easily.

Yep, extjs always uses MVC design. But changing the views would require removing the original view-class-files and adding new ones. Although this is of course possible (even without any dev environment, just by exchanging the js-files) I wouldn't want to integrate such a feature on the server side. Currently, the MPAynwhere plugin itself registers three paths (in the future maybe more) when it starts up. When another plugin later registers other paths, the files in these paths cannot "overwrite" the original MPAnywhere files. MPAnywhere will always return the first matching file it finds (whereas first means: first registered, first come - and MPAnywhere always registers first). That means you can add files by other plugins, but you cannot overwrite files provided by the MPAnywhere plugin. The idea behind it is that I want to avoid that some extension plugin breaks the core functionality of the original MPAnywhere plugin. Of course you can do that manually by just copying other files into the MPAnywhere wwwroot folder but hey, you cannot prevent a user from breaking a software if he really wants to

Hopefully though someone might come up with an awesome (animated, single page?) design we can use

I would really prefer a single page design - I want it to look like an application - not like a webpage.

Wouldn't it be easier to register all menuitems automatically also for the webservice or query the existing menuitem from the according module?

I think this is a misunderstanding, tomtom. MPAnywhere's menu has nothing to do with the MP2 client's menu. That would require us to provide all the functionality available in the MP2 client also on the MPAnywhere side. That would be really overkill... I think not all the functionality available in the MP2 client is necessary on the MPAnywhere side (why would you need OnlineVideos in MPAnywhere? You already have a browser in front of you and can easily go to youtube without onlineVideos). On the other hand, MPAnywhere can have functionality that is not available in MP2 client (editing MediaItemAspects in front of your TV with a remote would not really be fun).
So an MP2 plugin can register a menu item for the MP2 client (via the plugin.xml file) or it can register menu items for MPAnywhere (currently with the methods RegisterMenuItem as per the interface above). Of course an MP2 plugin can also register menu items for both - but in most cases I think this will not be the case.

I'm not sure how far you can use the plugin.xml file that comes with every plugin for MP2 but with the service registration (and I guess menu) couldn't that information be pulled from the plugin.xml.

Theoretically that is possible, but I can't see the advantage. Using the plugin.xml file would probably require changes to the core of MP2 to make the MP2 PluginManager understand the new xml-tags and I wanted to avoid that. Have a look into the MPAnywhere.EditMediaItemsPlugin.cs. Like every MP2 plugin it has an OnActivated method and in that method I register the additional virtual paths. The same way you could register menu items.
Do you see any additional benefit of using the xml-file instead of the OnActivated method besides that you don't have to recompile your plugin when you change your menu items?

That way the hosting URI, menu items required (maybe more than 1), etc. could also be configurable if say a conflict occurs (even a UI could be made to easily... tweak the settings).

That sounds a bit like the MP1-way But if you really want to tweak, you can easily move the js-files around and exchange them. The only thing you cannot tweak is in fact the menu items, which would be provided by a webapi - but why would you want to tweak them? A plugin should know what menu items it needs. And the only conflict I could imagine is that two plugins register a menu item with the same name - but this could be handled the MP2-way: Just add a "(2)" behind the menu text of the second one, do not throw an error and just run...
Or did I miss something here?

All that said I think your plugin must bind to *:{port} and all other plugins must supply a path but all still run on the same port. When someone browses the default page maybe have an error prompt if a conflict occurred.

That is already the case - besides the fact that a plugin can currently not lead to the core functions not working anymore - and this is intended.

If the information is pulled from a plugin file the loading order shouldn't matter so much as long as you can be notified once all plugins are loaded. The other good part about using plugin.xml is the project wouldn't (I think) require any special treatment to work with MP2 or IIS, etc. short of an xml file.

I don't understand what you mean here - could you please elaborate a bit on that? I don't see a difference in the loading order between using an xml-file and using the OnActivated method. The plugin will in its plugin.xml file define a dependency on the MPAnywhere plugin (see MPAnywhere.EditMediaitems.plugin.xml), which ensures that MPAnywhere is activated first. That wouldn't change using an xml-file.
Do you see any advantage of using IIS? Even if you have IIS installed, it wouldn't hurt that MP2 uses the selfhostserver - again this is my personal understanding of MP2: We make it as easily as possible to configure. No need to install IIS. Even providing the option to install it on IIS, this would require the user to make a choice when installing and I wouldn't like that idea...
But maybe I overlook something here...

I thought it would be a nice idea to have some important serverstats in the header and maybe some actions like restart etc. Will play a bit more with the layout this evening

Great Thanks! Is this a mock-up or did you change the js-files?

But another important point: How do we deal with localization? In the past I often used a template system in php, so you have vars like {my_var} which is replaced by the templatesystem, but any idea how to do it here? So that we can have the webinterface in german, english, ... I think we shoudl plan this right from the beginning otherwise it would be a huge workload to change everything again...

Already added to the ideas and missing feature list in the second post We can either use MP2's inbuilt localization service, but this would require to parse the js-files for strings and replacing the strings before providing the files to the browser - don't know if this is possible. Or we use the inbuilt localility of extjs. Or we use both: MP2-localization for the menu texts and extjs for the rest. Absolutely unsure about that....

Thanks for the great discussion, guys!
Michael

 

[FreakyJ]

thanks for the great answer.
I think we really have to define a good communication interface. This is a key point in the whole concept. You didn't comment my idea using post for all the communication? Would this be an idea?

Is this a mock-up or did you change the js-files?

I can't do mockups oO I changed the js file, nothing big, just 10min of work^^ I attached it just in case you want to have a look on it
Will probably do some more things this evening

Or we use the inbuilt localility of extjs.

I will take a look on the extjs localization feature late on But I feel like we should go with extjs... parsing the whole js file before serving it sounds not like a good option to me Also we will get some issues if you change the language because of the catching feature from the browser. The last time I used php to generated js source I had to do something like this: my_js.php?random={some_random_numbers} really ugly, but was working like a charm

 

[MJGraf]

So if I understand you right, the user basically has "MP2 in his browser", right?

Well this is still a looooong way to go, but in the end: yes, this is the "vision"

Yet the interface/gui is what will need a lot of attention. When you look at the app's available on i.e. iOS, then a "tree" will not quite cut it. What I mean is that there might should be 2 ways to access MP through the web. One that is more basic/admin'ish (i.e. to change configuration of a client/server? that would be pretty sweet ), and one (the default) that is fancy and eye-catching like:

I absolutely agree - and this is the reason why I planned different UIs for computers, tablets and phones. The computer UI (using extjs) will be the more basic/admin'ish UI. But I started this first, because Lehmden's idea was to have something to edit MediaItemAspects. That doesn't fit the fancy eye-catching UI and you woudn't want to edit the Album Artist for 100 mp3-files using a tablet...
The eye-catcher is planned for touch devices (using sencha touch).
That does of course not mean that we cannot provide a possibility to say "hey, I'm a computer, but please let me use the touch design, I want to have the eye-candy". That should be possible quite easily by providing a button in the different UIs.

As to the tree, well that was meant for the admin-UI. For the touch-UI I thought about how the email app on an iPhone works. On the left, you have your emails in something like a list (that's the first level menu items in our tree). When you have an email trail with several replys and you select that email trail, you see the emails contained in the email trail (that's the second level menu items of the first level item you selected). And so on... On the right you have the main panel with whathever you choose in the menu on the left.
But I have to admit that for the touch UI I haven't done anything, yet, besides making sure that it can be added later. To my understanding, sencha touch also has themes and there is also a "theme builder".
That means in the end, it would be possible to have something like in your video (Eve I suppose) IF (and only if) there is a talented designer to provide a theme for the touch UI. I have definitely no talent in designing

Nevertheless, we have to accept that a native app on e.g. iOS will always have more possibilities than a browser app (and maybe feel a bit "snappier"). But I am quite impressed what is possible with sencha touch in the browser. Have a look here (go there with your iPad) and enjoy... Then visit the site with your computer browser and you will see why I didn't use sencha touch for the computer UI

Michael

 

[MJGraf]

I think we really have to define a good communication interface. This is a key point in the whole concept. You didn't comment my idea using post for all the communication? Would this be an idea?

Well, I have to admit that there is still a lot to read for me regarding WebApi and OData. That's the reason why I cannot really comment on this, yet, as I have no idea what "best practice" is. I'll probably just start with filling my dummy APIController with life by connecting it with the MediaLibrary and then we can test different approaches how to tackle this. First I wanted to find the best solution for getting data from the MP2-server. That's a typical get-request, but even there I'm unsure how to implement it as regards queries.

The first question (already in the ideas/question list) is how we should transfer the MediaItems. Shall (or can?) we us our MediaItem objects directly or shall we make some kind of a wrapper object? No idea yet: try and error...
Once this is clear, the question is how to we get those MediaItem(Wrapper)Objects:

The easiest is of course "Get me the MediaItem with ID {xyz}". That would be

http://MP2ServerName:81/api/MediaItem/{xyz}

We would probably need some kind of filtering possibility along the lines of "give me all MediaItems that have an AudioAspect"
(This on the other hand requires that we have a separate controller that provides all the registered MediaItemsAspects, because there may be additional Aspects added by MP2-plugins and our API should be able to handle them without any code changes. But let's talk about this later...)
This could be something like:

http://MP2ServerName:81/api/MediaItem?Aspect=AudioAspect

But then I suppose we should also have something like "give me all MediaItems with AudioAspect's AlbumArtist like'%queen%'"
That's similar to what I already mentioned above for changes and could for getting objects look like:

http://MP2ServerName:81/api/MediaItem?Aspect=AudioAspect&Property=AlbumArtist&value=%queen%

But what if we want to search based on two properties? Then we would really need to parse the URI "Manually" and filter our search criteria by analyzing the string. If we really want this, it might be better to do it right and implement "IQueryable", which would enable us to use OData.

Don't know what the right way is, yet...

And once we have the implementation for getting objects, we need the implementation for Delete (probably easisy by ID), CREATE and CHANGE. The latter ones are the ones you are mentioning and currently I think we will need POST-requests for that...

Michael