new class - diff ?

[code reader]

i noticed (a bit late, i admit) the addition of a new class to the code - diff.
looking at the code, it seems that a large portion of it was taken from another project (PEAR).
first, i want to congratulate the dev team. i dont think its a first, but i do see here significant deviation with what was perceived to be a hard case of NIH mentality.
second, i want to express hope that this new code will be used to implement automatic update mechanism.
third, i beg the developers to seriously look into using the same set of tools to implement an effective package-management system (with all due respect to easymod, in its current state it falls short)

and last, some thoughts about what is the right way to incorporate "foreign" code into a live project.
in my experience and my opinion, it is best to leave the imported toolset as untouched as possible. if you need some extra functionality that does not exist in the imported toolset, it is best dealt with (if possible) by inheritance.
if you find that it is absolutely necessary to insert a change into the imported library, you do it in a very controlled and limited manner (btw: cvs has guidelines and instructions of how to deal with what they call "vendor code").
this way, it is much easier to incorporate enhancement and bug fixes supplied by the original vendor of the code. it also helps you get into the mindset of "libraries", "modules" and "api", in contrast with a monolithic piece of code.

with all the above said, i want to make my main sentiment clear again: kudos to the devs for this important development.

[Acyd Burn]

We used third party code before... just have a look at the authors file.

I already wrote this somewhere else, but stating this again might help:

[...] we are of course adapting third party packages - but only if it is possible. The main reasons for not including third party code are:

- the code is not able to be abstracted enough, for example not being a seperate component, if it influences too much core code.
- the code is having too many features - if we strip it down we are presented with something we can write on our own.
- code fragments
- not matured code

There are other reasons too, not very objective ones though.

second, i want to express hope that this new code will be used to implement automatic update mechanism.

Are you submitted to the cvs-checkins email list? If yes, read the emails again you received.

[JuliusCaesar]

Are you submitted to the cvs-checkins email list? If yes, read the emails again you received. Wink

so there will be an automatic update mechanism in the final version,right????

[Basti504]

9/2/06 4:34 PM acydburn
the file updater. This is in CVS but the file is not able to be used without the correct update packages - no need to try.
Please note that even if the file is now in CVS it does not mean we provide an update path from Beta2 to any other version. (3 Files changed, 1467 Lines changed)
install/install_update.php 1.1 added 1009
adm/style/install_update.html 1.1 added 278
adm/style/install_update_diff.html 1.1 added 180

Sounds good

[Acyd Burn]

Are you submitted to the cvs-checkins email list? If yes, read the emails again you received. Wink

so there will be an automatic update mechanism in the final version,right????

I do not like the expression "automatic update" since such a thing is currently not possible for web applications - not in a way a user might be used to; their favourite automatic software package updater.

But yes, a file update tool will be included. This updater works by obtaining differences between the new/updated, old and currently installed file. Based on the files state the changes will be merged or the file normally overwritten (conflicts will be detected too). The changed files are able to be downloaded and able to be ftp'd in, depending on what the user want and have. Special update packages will be provided to utilize this method.

[code reader]

thanks, acyd.
1) if you read my original message, i did write "i dont think it's a first". otoh, it is a first in a very very long time...
2) in addition to working with ftp and local files, please consider working with either remote file, or with remote db access (or both) this is one step further towards "automating" the update process.
3) what are the chances of extending this mechanism to a full-fledged package manager (ie, using it for modding as well as updates)?
4) will the infrastructure include the capability of removing a previously applied update ("reverse patch")? please consider positively, as it is possible that an unforeseen problem will be detected in a patch.

people have been bitching about phpbb security for a long time. in general, the team was quite good at providing security patches. the main problem, as i saw it, was that people were very "lazy" about applying updates. it is easy to blame the users, but the difficulty of applying updates played a major role in the large number of pbpbb boards which are out-of date, and hence to the security issue.

a "one-click update" (in contrast with "automatic update") will a huge step forward, and is the most important and effective thing that can be done to enhance phpbb security.

again, kudos to the dev team for this timely addition. imo, this even worth delaying the final version by some months. (and no, i do not subscribe to the "cvs mailing list". is it possible to add a "read only" forum to area51 with all the messages in the ML ?)

[Acyd Burn]

2) in addition to working with ftp and local files, please consider working with either remote file, or with remote db access (or both) this is one step further towards "automating" the update process.

Since the install folder needs to be on the server it would be illogical to work with remote updates. Please note that this is solely for updating phpBB and not meant for installing mods.

3) what are the chances of extending this mechanism to a full-fledged package manager (ie, using it for modding as well as updates)?

Very minimal. The MOD Team most likely will use a similar method later, but we do not intend to create a package manager.

4) will the infrastructure include the capability of removing a previously applied update ("reverse patch")? please consider positively, as it is possible that an unforeseen problem will be detected in a patch.

No, but backups of the files will be made. Conflicts are detected too in prior of patching.

it is easy to blame the users, but the difficulty of applying updates played a major role in the large number of pbpbb boards which are out-of date, and hence to the security issue.

I would say even now we provide the easiest method of updating - changed files between releases, patch files, complete files and code changes.

i do not subscribe to the "cvs mailing list". is it possible to add a "read only" forum to area51 with all the messages in the ML ?)

http://sourceforge.net/mailarchive/foru ... um_id=2657" target="_blank

[code reader]

acyd,
first, thanks for taking the time to relate and answering the question in a serious and respectful manner. i really do appreciate this.
second, i do not wish to make this an argument, but i would like you to re-consider one issue:

Since the install folder needs to be on the server it would be illogical to work with remote updates. Please note that this is solely for updating phpBB and not meant for installing mods.

it is probably an oversite on my side, but i don't see the connection between "the install folder should be on the server", and "it will be illogical to work with remote updates".
the location of the "update server", i.e. the server where the update files are held can be hardcoded to reduce the risk of highjacking. the system could open (remotely) a file listing all the available updates, make a decision which of them is relevant, display the list, and if the admin choses one of them, it could aqcuire the appropriate remote file containing the diffs and db changes.

even today, with phpbb2, the system opens a socket to phpbb.com in order to find whether the current version is the latest one. it would not be so radical to walk the extra step and obtain the diff file in the same (or similar) manner.

as to the "MOD team using a similar method later": why should they use a similar method, instead of using the exact same method? it makes much more sense to use one good library, instead of creating an (almost but not quite) identical functionality?

as to phpbb supplying the easiest way of doing updates among bbs systems: imho, this is not the case.
even if the user has easymod installed (and this is not the default), she has to upload the update file to the host using ftp, and then use easymod to apply it. not overwhelmingly complicated but far from a "single click update". anyone else will be required to actually edit code files manually, or overwrite files with the added risk of undoing a local changes (MODs).
other packages offer automated process that does not require ftp or editing, even when modifications were applied.
i expressed the hope that phpbb can provide this level of convinience, and my opinion that doing so will be the best thing you can do to enhance phpbb security: if, next to the red "You are not running the latest" message we see today in admin panel there will be a button "Update now", the number of systems running outdated code would drop so dramatically, that it would stop being the major issue it is today.
of course, having a "rollback" option will add great comfort. ie, if users will know they can roll back updates if/when problems appear shortly after an upgrade, they will be that much more likely to apply the update as soon as it becomes available.

[Acyd Burn]

acyd,
first, thanks for taking the time to relate and answering the question in a serious and respectful manner. i really do appreciate this.
second, i do not wish to make this an argument, but i would like you to re-consider one issue:

Since the install folder needs to be on the server it would be illogical to work with remote updates. Please note that this is solely for updating phpBB and not meant for installing mods.

it is probably an oversite on my side, but i don't see the connection between "the install folder should be on the server", and "it will be illogical to work with remote updates".
the location of the "update server", i.e. the server where the update files are held can be hardcoded to reduce the risk of highjacking. the system could open (remotely) a file listing all the available updates, make a decision which of them is relevant, display the list, and if the admin choses one of them, it could aqcuire the appropriate remote file containing the diffs and db changes.

The update is taking place on the server, the same as installing phpBB3.

[Acyd Burn]

One addition i forgot:

the location of the "update server", i.e. the server where the update files are held can be hardcoded to reduce the risk of highjacking.

To reduce the risk of hijacking we do not have an "update server" at all. There will be update packages downloadable from the known locations. The package needs to be uploaded uncompressed - it contains only an install folder. Then the user need to follow the link to the update location.