Need some change in the MP ISetupForm for webinterface (2 Viewers)

[samuel337]

That's much better - thanks for that.

You can ignore all my previous posts - they were irrelevant.

I suggest that instead of using the ISetupForm interface to work out the version, just use .NET's internal version property. You can work this out using the code I provided above. This way it provides better backwards compatibility - but that's just my suggestion; let's see what the devs think.

Sam

 

[mPod]

French CVS? rofl

Any reasons why you're not working together with the official team and found an independant sub-team instead? That's very bad IMO. You will always have the problem that your stuff has to be approved by the official team this way. Furthermore there is no communication between the official team and your "sub-team". I suggest you think your model over a bit...

Back to topic:

1. ISetupForm will not be changed, this will render all older plugins unusable. As some plugins are not maintained anymore or the devs have lost the sources, this would mean trashing those plugins without never having a fixed version. The way to go would be version management via XML and file dates and/or sizes or .NET versioning system. The .NET versioning system (or your approach with changing ISetupForm) would only work with plugins and not with other stuff (skins, lang packs, whatever stuff that doesn't include assemblies).

2. The web server hosting the packages will be hosted by Luke. So if you really have to install stuff on a web server, I suggest talking to him first what is possible and what is not. (Luke is part of the official team, one of those communications issues you have, as I mentioned before!)

3. The installer has to work for everything related to MediaPortal. Language files, skins, plugins, whatever. If we will have other plugin classes in the future (unlikely), the installer system doesn't have to be changed because of such. So keep this in mind and build the stuff open, so that future additions/changes to the installer system won't break all other existing installer packages. Once a package is build it has to work with all future versions of the installer. This is very important!

4. Updates have to be incremental. If it's not, then if e.g. a skin dev changes a single line or gfx the whole skin package would have to be downloaded. In that case only the changed xml or gfx file should be downloaded. This saves traffic & time for the user and the web server.

5. For security reasons the contents of the XML installer file (or all other files) might have to be scrambled in the future. Take this into account and make the installer future proof for this as well. Security stuff is no issue atm but might get more important in the future. As said, extending the installer with such features may not break older packages.

6. Update check may not occur on every MP start. Several days should be in between. (Reson: See 4)

7. It is very important that the server interface (in & out) does not allow any backdoors, so hackers cannot hijack the system and harm our users.

Those points are not open for discussions, they are the prequisites for your system to be approved and adopted by the official team.

 

[guilhem]

French CVS? rofl

It's just a server CVS for plugin. There is not Media Portal on it.
With this server, we can develop a plugin with few developers. It's just a facility for plugin developer. It's a possibility to keep the code source of plugin when the developer disapear
And i don't find this type of server CVS in the official team. but maybe it already exist...

To conclude, we want to work with official team and i don't think we are an "independant sub-team"

As i work on the PHP web server, i'll go to send a mail to Luke to speak what the web server need and wath we can do together.

 

[mPod]

As i work on the PHP web server, i'll go to send a mail to Luke to speak what the web server need and wath we can do together.

Sounds good.
I decided that we're going to trial your development (100%) in case you follow the prequisites listed. This saves me/us very much time & work. Before we put it into the official distribution, we're going to trial & test it with our test team, as usual.

Take your time, better do it 100% than later being sorry cause major changes have to be done. As said, the most important thing is that it is future proof and the packages will be upwards compatible.

We always need talented developers, so if you are, you're welcome to join the team. It would be good (at least at a later stage), if you would be around on IRC regularly so that the test team and devs have the possibility to talk to you. The updater system is a very important point for us.

One more important thing: We won't start caring about your development until AFTER 0.2 release, cause we're in a late release phase and don't accept new stuff to get the release stable. This also includes your updater system. So no hurry, no pressure, you have plenty of time to make it all perfect. :wink:

We got a deal here?

 

[pitie]

French CVS? rofl
yes for all french development.

Any reasons why you're not working together with the official team and found an independant sub-team instead? That's very bad IMO. You will always have the problem that your stuff has to be approved by the official team this way. Furthermore there is no communication between the official team and your "sub-team". I suggest you think your model over a bit...
Yes we want working with you (it is why i come some times on irc and i mail some of the dev team)
Back to topic:

1. ISetupForm will not be changed, this will render all older plugins unusable. As some plugins are not maintained anymore or the devs have lost the sources, this would mean trashing those plugins without never having a fixed version. The way to go would be version management via XML and file dates and/or sizes or .NET versioning system. The .NET versioning system (or your approach with changing ISetupForm) would only work with plugins and not with other stuff (skins, lang packs, whatever stuff that doesn't include assemblies).
Ok, the main setup file in the mpi is a xml file so i will add this version entry (major.minor)

2. The web server hosting the packages will be hosted by Luke. So if you really have to install stuff on a web server, I suggest talking to him first what is possible and what is not. (Luke is part of the official team, one of those communications issues you have, as I mentioned before!)
ok, Guilhem will contact him

3. The installer has to work for everything related to MediaPortal. Language files, skins, plugins, whatever.
yes it is
If we will have other plugin classes in the future (unlikely), the installer system doesn't have to be changed because of such. So keep this in mind and build the stuff open, so that future additions/changes to the installer system won't break all other existing installer packages. Once a package is build it has to work with all future versions of the installer. This is very important!
yes it is really important and i have made a system that if we must upgrade it, for exemple if the <file> comand must get more function, it is able to go to <file2> and the same for, REG, INI, LANG, INFO...

4. Updates have to be incremental. If it's not, then if e.g. a skin dev changes a single line or gfx the whole skin package would have to be downloaded. In that case only the changed xml or gfx file should be downloaded. This saves traffic & time for the user and the web server.
interesant... I don't do this. So if i understand, for exemple i downloaded v1 of a plugin and if 3 other version are out it must install the 3 other version ?
For now, it unistall last version and install the new one but i can change it (i think...)

5. For security reasons the contents of the XML installer file (or all other files) might have to be scrambled in the future. Take this into account and make the installer future proof for this as well. Security stuff is no issue atm but might get more important in the future. As said, extending the installer with such features may not break older packages.
yes we can use the ZIP password to protect it ?
Or we can only crypt some file ?
but as you say for now the most important is to do a perfect version and stable so we will do this after

6. Update check may not occur on every MP start. Several days should be in between. (Reson: See 4)
Yes i was thinking about 7 day MINI but after it is possible to change it to more


7. It is very important that the server interface (in & out) does not allow any backdoors, so hackers cannot hijack the system and harm our users.
yes sure

Those points are not open for discussions, they are the prequisites for your system to be approved and adopted by the official team.
yes i understand all (i think) and a lot was envisaged

 

[pitie]

As i work on the PHP web server, i'll go to send a mail to Luke to speak what the web server need and wath we can do together.

Sounds good.
I decided that we're going to trial your development (100%) in case you follow the prequisites listed. This saves me/us very much time & work. Before we put it into the official distribution, we're going to trial & test it with our test team, as usual.
it apper to be normal

Take your time, better do it 100% than later being sorry cause major changes have to be done. As said, the most important thing is that it is future proof and the packages will be upwards compatible.
yes. I understand

We always need talented developers, so if you are, you're welcome to join the team. It would be good (at least at a later stage), if you would be around on IRC regularly so that the test team and devs have the possibility to talk to you. The updater system is a very important point for us.
and it could do a more connection with all french dev.
But for now i think we have to wait to end of this project...
I come 2 day // 7 on the IRC but if you need to speak to me I can give you my MSN

One more important thing: We won't start caring about your development until AFTER 0.2 release, cause we're in a late release phase and don't accept new stuff to get the release stable. This also includes your updater system. So no hurry, no pressure, you have plenty of time to make it all perfect. :wink:
Yes sure we have time but it is a big project and you will able to test it soon

 

[mPod]

Yes sure we have time but it is a big project and you will able to test it soon

As said, all devs & the test team are busy with the 0.2 release until it's out so testing the updater system can only start after the release. Problem is as well that many of us are currently busy with job & other (non-MP) stuff so it's also progressing a bit slower than usual. Not saying that your bunch can start testing it all before. I hope you understand this and it's no problem for you.

 

[pitie]

not a problem

 

[CHli]

Hi everyone,

I'm very happy to see that the french forum is joining the common effort !

Just a note about this, cause I think there is misunderstanding :

4. Updates have to be incremental. If it's not, then if e.g. a skin dev changes a single line or gfx the whole skin package would have to be downloaded. In that case only the changed xml or gfx file should be downloaded. This saves traffic & time for the user and the web server.

interesant... I don't do this. So if i understand, for exemple i downloaded v1 of a plugin and if 3 other version are out it must install the 3 other version ?
For now, it unistall last version and install the new one but i can change it (i think...)

French see below :

What he means is that if only one file of the plugin has been modified the autoupdater should not download all the unmodified file to update to the new version.

French version:

Ce qu'il veut dire c'est que si un seul fichier du plugin a été modifié la mise à jour automatique doit le détecter et télécharger que le fichier modifié et non pas tout le package.

 

[mPod]

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).