Need some change in the MP ISetupForm for webinterface (1 Viewer)

[samuel337]

Speaking if Windows Update, does this use the BITS (Background Intelligent Transfer Service) feature in Windows XP? It would save you a lot of time and effort in coding resumable download features, as well as allow the downloads to continue even if MP has closed for whatever reason.

Sam

 

[guilhem]

Chili is right, I think. An example:

Package of Version 1
===============
fileA
fileB
fileC
fileD

Update package to Version 2 (only fileB has been changed)
====================
fileB

Update package to Version 3 (only fileB & fileC have been changed)
====================
fileB
fileC


So at the end we have the following files on the server:

Full Version 1
Full Version 2
Full Version 3
Update Version 1 -> 2
Update Version 2 -> 3

OR

Full Version 1
Full Version 2
Full Version 3
Update Version 1 -> 2
Update Version 1 -> 3

(But I think that is not that good, cause what happens if user starts with Full Version 2? This would mean we would also have to offer a package for Update Version 2 -> 3, could be that it all gets a bit much - although with some client/server intelligence it's all doable.)

I hope this makes sense, maybe you have some ideas to add here. But roughly that should be the idea. "Windows Update" is quite successful, so it can't harm to adopt some nice ideas from there (or other update systems).

Your solution seems very interesting but it is complecated to. At final, we need to make a complex algorithm which can manage automatically :
Full Version 1
Full Version 2
Full Version 3
Update Version 1 -> 2 (calculating diffrence between 1 and 2)
Update Version 1 -> 3(calculating diffrence between 1 and 3)
Update Version 2 -> 3(calculating diffrence between 2 and 3)

Without speak of the place storage, i think it's complicated to implement un automatical systeme.

We can think that the creator make theses differents packages( he is the only person to know what need to change) . And the web site, propose the downlod off all package. The user can choose, maybe he prefers a complet reinstall.

And maybe the creator have completely, rebuild his plugin so it's a need a complet instalation.

 

[mPod]

I think that should be part of the packaging manager application. It gets the information from the server (from the db or some xml files) and knows what files have to be updated and builds the appropriate packages based on that information. The developers who want to upload shouldn't have to care about that, this would be too complicated for them. So it's not the server who packages the stuff, it's the packaging app which builds the package(s) based on the information it can get from the db on the server. And when uploading the finished package(s), it tells the server what it has to enter into the db. So the information exists the next time such a package has to be build. Quite tricky, I know. I hope you get what I mean.

 

[pitie]

Yes i understand

The big problem is that the dev send a MPI FIle with all file so the server will must decompress it if we must implement it so ressource will be used a lot...

or a exemple a standart plugin do ~500ko(by zipping 50ko), a skin, about 25Mo (for exemple, bluetwo in 23mo by zippin it => 14) so you must tell me it now because it chang a loot of thing

If the user must download all file or just MPIfile

All file :
Take space and transfer error. (server must send more file and Ko)
But easy for user and only changed file updated after some server send not more

MPI :
Easy transport (1unique file) Space is more optimised (zip compress)
But each update must be downloaed totaly

...

 

[mPod]

No, not the server does it. It's the app that builds the MPI packages. So that app will produce several packaged files that are uploaded to the server and updates the db on the server accordingly.

The main reason behind this all is that the traffic for the server has to be minimized. Also the traffic for the enduser should be as low as possible. Some have traffic based accounts, keep that in mind. Let's not produce unneeded traffic on both sides.

Also the server should be as dumb as possible, all intelligence should be in the packaging/uploading app and in the mp client for the enduser. Processing power on server is too worthy than spending it on such stuff, if not needed.

 

[guilhem]

No, not the server does it. It's the app that builds the MPI packages. So that app will produce several packaged files that are uploaded to the server and updates the db on the server accordingly.

The main reason behind this all is that the traffic for the server has to be minimized. Also the traffic for the enduser should be as low as possible. Some have traffic based accounts, keep that in mind. Let's not produce unneeded traffic on both sides.

Ok i understand what you say.
The MPI maker or whatever which produce the first package, make a file (maybe xml) with the list of included files and their checksum. The package and this files are stocked on the web site.

Another plugin version, the mpi maker reload this file and compare the list of file and checksum and can build a full package and a update pakage.

Pitie there is not difference for the MPI file and his installation or uninstallation but the difference is on the MPI maker and on the web site. Maybe on MPI you need to pricise if there is an existing version of plugin needed for installing...

 

[mPod]

Yes! :lol:

 

[pitie]

ok i will chat with guilhem by MSN lol (i don't understand all lol)

but i think ther is an other possibility, MPI maker can upload the new version and an update from the last version ?

 

[mPod]

ok i will chat with guilhem by MSN lol (i don't understand all lol)

Yeah, some things are not easy to explain and can easily get complicated. Especially we're both not native english speakers. But as long as one of you understands what I'm talking about, I'm happy with it. :wink:

but i think ther is an other possibility, MPI maker can upload the new version and an update from the last version ?

Yes, that's one of the things i tried to explain. So one possibilty would be a base package and some update packages. An xml (or the db) on the server keeps track of them and the update application decides what is necessary for download. It's all a bit complicated, so I'm open for any suggestions at that point. But I guess you (and guilhem) got the idea what I'm driving at.

 

[mPod]

One thing we didn't talk about yet...
Does your system also contain a section in MediaPortal where all downloadable plugins are categorized and listed? This gives us great opportunities, cause we only need to have basic stuff in our official MediaPortal distribution then.
The user sits on the couch and chooses with his remote control what plugin he wants to install. Do you know Linux' YAST? That's one example of a list with installable modules (in our case plugins or skins or...).
So the user does not have to use a web browser to download the initial version of plugins and can do all integrated in MP's GUI with the press of his thumb.