MPAnywhere - a proof of concept for an MP2 webservice and webinterface (1 Viewer)

[FreakyJ]

another short question: is it possible to use php with this webstack? Maybe it would be useful for some things

 

[MJGraf]

Nope, as far as I know so far, php is not supported. Only Asp.Net.

One further note to the requests to the API. According to this it says:

GET requests should be used only to retrieve data

That means for Reading data from the server we should use "Get".
For anything else (Create, Update, Delete) we should use "Post".

 

[FreakyJ]

That means for Reading data from the server we should use "Get". For anything else (Create, Update, Delete) we should use "Post".

sounds pretty good to me Also get and post suggest this scenario in their names already

Maybe you are able to take more care of the backend stuff, as I said I will try to do more on the HTML front this evening So if you have the medialibrary in a stage where it delivers data can you post an updated version of your plugin? I'm no webdev, but I wrote already some big webaplications like an own image galary with ajax which host its pictures on different servers etc... So maybe I could help you in some way here

 

[MJGraf]

Correcting myself:
For Creating: http-Post
For Reading: http-Get
For Updating: http-Put
For Deleting: http-Delete
Source for this is here. And it also states that for Post requests, it expects the data of complex types in the body of the request.

 

[MJGraf]

Maybe you are able to take more care of the backend stuff, as I said I will try to do more on the HTML front this evening So if you have the medialibrary in a stage where it delivers data can you post an updated version of your plugin? I'm no webdev, but I wrote already some big webaplications like an own image galary with ajax which host its pictures on different servers etc... So maybe I could help you in some way here

That would be really great! Thanks for that. I'll try to do some more work on the backend tonight - but first I have to do something for my RL-job

 

[infinite.loop]

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

I don't have an i-pad.
But will try to checkout that site somehow.

 

[MJGraf]

Any touch device would be ideal. You can also go there with a regular browser and you may guess what it feels like on a touch device. But it isn't really fun to use the mouse for clicking on buttons designed for being used with your fingers

 

[MJGraf]

Oh and another question I have for anyone who has ever worked with a js-framework (such as sencha extjs, jquery or the like) in Visual Studio in combination with GitHub:

The original download of extjs is a zip-file with nearly 70MB. You certainly don't want this in GitHub and I also don't want this in my Visual Studio project. There are a lot of examples in it and also the whole documentation.

What I currently copied to my VS project from extjs is all contained in the wwwroot\computer\extjs folder of the MPAnywhere plugin. We have:

• ext-all-dev.js
  • about 6MB, which is the development version of the whole extjs library. For deployment we can also use the ext-all.js, which is about 1.5MB in size, but the dev-version is not minified, includes JSDocs and provides very useful console information for debugging when using FireBug).
• wwwroot\Computer\extjs\resources\css\ext-all-access.css
  • about 1kb, needed for the "Accessibility Theme" I currently use
• wwwroot\Computer\extjs\resources\ext-theme-access\*.*
  • These are some further css-files used for the Accessibility Theme (alltogether 1,66MB and I just realized that we probably only need one of them...) and
• wwwroot\Computer\extjs\resources\ext-theme-access\images\**\*.*
  • This is a whole bunch of images that finally make up the Accessibility Theme (alltogehter about 1,78 MB)

Now a few things come thogether:

First of all I think we should use Nuget for everthing that is original source files from sencha. No need to push it in our repository.
But what should we include in the Nuget-Package? The whole 70MB files? Only the ones we need? Are we even allowed under GPLv3 to include only some of the sources? Is it possible to specify in the Nuget package that we don't want to have all the files in it in our Project directory and only download all the files to the .packages directory?

It's quite clear then that we use the build.targets file to copy the necessary files to the $(PluginDestination) folder in the AfterBuild-Event.
But do we also copy all/some of the files to our $(ProjectDir)? I haven't tried, yet, but I think it would be very useful to include the ext-all-dev.js in VisualStudio's intellisense (which I read somewhere in the internet is possible). For that I suppose (please correct me if I'm wrong) we would have to copy it to the Project directory (or a subdirectory of it). But then we have to GitIgnore this directory to prevent it from being pushed to Git.

Next question is: How do we deal with debug builds (with ext-all-dev.js) and non-debug builds (with ext-all.js). Is there a way to specify the different files to use in the build.targets file?

Is there any known best practice for this? I can't really be the first one to think about this...
@chefkoch you're the Nuget-master - any thoughts on this?

Thanks, Michael

 

[Lyfesaver74]

Sorry if I am re-posting, but I did not read this entire thread. I like your enthusiasm, but I am left with a question that puzzles me. My question is why rebuild the wheel? MPE/WebMP/aMPdroid and the like already work well. We just need to include the ability to read MP2 databases. Done. Or do we want to have ANOTHER area where MP1 can compete with MP2?

 

[offbyone]

MP2 brings an entirely new architecture to the table.
- MP2 Server that already always runs as service (no need to install an additional Service as for MP1)
- MP2 abstracts it's database - it is not a good idea to directly access it - rather use the provides core code classes
- There are not x plugins of which to read the DB from - only a single DB with MediaItems of different types

But I agree we must not create everything from scratch and I would like to get @Oxan to have an eye on this project (which is in very early stage - so no final on anything). This is not here to "compete" with MPExtend - rather be what MPExtend was for MP1 - directly integrated in MP2. Everyone wants to work together - pls don't make it again about MP1 vs MP2!