Reply to thread

Message

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.

<blockquote data-quote="mPod" data-source="post: 51858" data-attributes="member: 11199">French CVS? roflAny 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 &quot;sub-team&quot;. 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 &amp; 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 &amp; 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.</blockquote>

[QUOTE="mPod, post: 51858, member: 11199"] 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. [/QUOTE]