From: Bruce R. <its...@uk...> - 2003-02-27 10:59:43
|
I had a thought that might be helpful for plugins and (I think) for the main SM code. I was looking at the code for the autocomplete plugin, where pdontthink has added functions to emulate sqextractGlobalVar etc to enable the plugin to be used with older versions of SM. It's a good idea but if every plugin author does it then there's a lot of effort being duplicated. My idea is to create a Compatibility plugin, which could check the version of SM being used and where necessary include files containing the missing functions. This would make it much easier to write plugins that could be used by those still using SM 1.2.8 etc (and there are plenty, for various reasons): a plugin author could simply say "If you are using an SM version earlier than X, you need the Compatibility plugin before this one will work". It wouldn't be hard to do a plugin that provided compatibility across 1.2.x and with a bit more thought plugins written for 1.4.x could be catered for. But I also think it could help the main SM code. There's a fair bit of legacy emulation in the core code (e.g. creating the $_POST and $_SESSION arrays for older versions of PHP) which makes it larger and a bit less readable than it would otherwise be. I think a lot of that might be moved into the Compatibility plugin. Not only would it improve the readability of the main code, it would improve speed, since the legacy code need only be included when an older version of PHP is detected. The more recent versions of SM wouldn't need to enable the plugin at all and so even the checks would be skipped. If that second, more ambitious proposal were adopted, then the Compatibility plugin should become one of the core plugins in the latest version of SM (whenever the plugin becomes a reality) and made available as a separate plugin for older versions. Then the warning would be "If you are using SM version earlier than X or PHP version earlier than Y, you will need the Compatibility plugin". Thoughts? --=20 Bruce The ice-caps are melting, tra-la-la-la. All the world is drowning, tra-la-la-la-la. -- Tiny Tim. |
From: Jonathan A. <jo...@sq...> - 2003-02-27 15:31:21
|
Hello Robert, On Thursday, February 27, 2003, Robert L. Tom wrote... > Where can I download older version of SM like 1.2.8? > The .tar.gz? It's called the sourceforge website. There are a long list of our released files there. http://sourceforge.net/project/showfiles.php?group_id=311 Hope that helps. -- Jonathan Angliss (jo...@sq...) |
From: p d. t. <pdo...@an...> - 2003-02-27 19:38:30
|
Dave had just mentioned the same thing on IRC yesterday; there is some amount of duplication going on that would be nice to avoid. A month or so ago, a couple folks on the devel list came up with the check_SM_version function, which is currently duplicated across several plugins. And I've been adding some of the functions like check_php_version and sqsession_register to many plugins in order to achieve backward compatibility (the functions are only called if an old version of SM is being used). Your idea seems useful if only to avoid so much duplication of code. I am not convinced that we need to pull out code from the core (is there really *that* much that makes it unreadable/waste cycles?), although it could be argued that as there continue to be changes in both php and SM, SM could be kept "pure" and fast, and compatibility would be left as an extra for those who had older systems. Thing is, this violates some of the organization of the core, specifically initialization routines -- if we did what you suggest, a specific call to include that plugin would have to be made in a place entirely different than any of the other plugins. That's not horrible, since this "plugin" is meant for something very different, but still... For now, I can pull the first part of your proposal together in a few minutes with a sample plugin that uses it. Stay tuned... > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf Of Bruce > Richardson > Sent: Thursday, February 27, 2003 3:00 AM > To: squ...@li...; > squ...@li... > Cc: pdo...@ph...uce > Subject: [SM-PLUGINS] Suggestion: a compatibility plugin > > I had a thought that might be helpful for plugins and (I think) for the > main SM code. I was looking at the code for the autocomplete plugin, > where pdontthink has added functions to emulate sqextractGlobalVar etc > to enable the plugin to be used with older versions of SM. It's a good > idea but if every plugin author does it then there's a lot of effort > being duplicated. > > My idea is to create a Compatibility plugin, which could check the version > of SM being used and where necessary include files containing the > missing functions. This would make it much easier to write plugins that > could be used by those still using SM 1.2.8 etc (and there are plenty, > for various reasons): a plugin author could simply say "If you are using > an SM version earlier than X, you need the Compatibility plugin before > this one will work". It wouldn't be hard to do a plugin that provided > compatibility across 1.2.x and with a bit more thought plugins written > for 1.4.x could be catered for. > > But I also think it could help the main SM code. There's a fair bit of > legacy emulation in the core code (e.g. creating the $_POST and > $_SESSION arrays for older versions of PHP) which makes it larger and a > bit less readable than it would otherwise be. I think a lot of that > might be moved into the Compatibility plugin. Not only would it improve > the readability of the main code, it would improve speed, since the > legacy code need only be included when an older version of PHP is > detected. The more recent versions of SM wouldn't need to enable the > plugin at all and so even the checks would be skipped. > > If that second, more ambitious proposal were adopted, then the > Compatibility plugin should become one of the core plugins in the latest > version of SM (whenever the plugin becomes a reality) and made available > as a separate plugin for older versions. Then the warning would be "If > you are using SM version earlier than X or PHP version earlier than Y, > you will need the Compatibility plugin". > > Thoughts? > > -- > Bruce > > The ice-caps are melting, tra-la-la-la. All the world is drowning, > tra-la-la-la-la. -- Tiny Tim. |
From: p d. t. <pdo...@an...> - 2003-02-28 00:28:26
Attachments:
compatibility-1.0.tar.gz
autocomplete.2.0-1.0.0.tar.gz
|
As promised, here is a first cut at a compatibility plugin. I think it came out fairly clean and will indeed cut down on function duplication and help retain plugin compatibility across most SM versions in wide use. There are instructions and examples on how to use it in the README file (as well as a sample of how to change your plugin's setup.php into the recommended format to help SM be the fastest, best webmail around!). The attached autocomplete is a beta, but seems to be a good working example of how to use the compatibility plugin... it works with most any version of SM as is. What do people think? - paul > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf Of Bruce > Richardson > Sent: Thursday, February 27, 2003 3:00 AM > To: squ...@li...; > squ...@li... > Cc: pdo...@ph...uce > Subject: [SM-PLUGINS] Suggestion: a compatibility plugin > > I had a thought that might be helpful for plugins and (I think) for the > main SM code. I was looking at the code for the autocomplete plugin, > where pdontthink has added functions to emulate sqextractGlobalVar etc > to enable the plugin to be used with older versions of SM. It's a good > idea but if every plugin author does it then there's a lot of effort > being duplicated. > > My idea is to create a Compatibility plugin, which could check the version > of SM being used and where necessary include files containing the > missing functions. This would make it much easier to write plugins that > could be used by those still using SM 1.2.8 etc (and there are plenty, > for various reasons): a plugin author could simply say "If you are using > an SM version earlier than X, you need the Compatibility plugin before > this one will work". It wouldn't be hard to do a plugin that provided > compatibility across 1.2.x and with a bit more thought plugins written > for 1.4.x could be catered for. > > But I also think it could help the main SM code. There's a fair bit of > legacy emulation in the core code (e.g. creating the $_POST and > $_SESSION arrays for older versions of PHP) which makes it larger and a > bit less readable than it would otherwise be. I think a lot of that > might be moved into the Compatibility plugin. Not only would it improve > the readability of the main code, it would improve speed, since the > legacy code need only be included when an older version of PHP is > detected. The more recent versions of SM wouldn't need to enable the > plugin at all and so even the checks would be skipped. > > If that second, more ambitious proposal were adopted, then the > Compatibility plugin should become one of the core plugins in the latest > version of SM (whenever the plugin becomes a reality) and made available > as a separate plugin for older versions. Then the warning would be "If > you are using SM version earlier than X or PHP version earlier than Y, > you will need the Compatibility plugin". > > Thoughts? > > -- > Bruce > > The ice-caps are melting, tra-la-la-la. All the world is drowning, > tra-la-la-la-la. -- Tiny Tim. |
From: p d. t. <pdo...@an...> - 2003-02-28 00:59:42
Attachments:
compatibility-1.0.tar.gz
autocomplete.2.0-1.0.0.tar.gz
|
My apologies. There were a couple of (crucial) typos in the previous attachments I made. Here are replacements. - paul > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf Of p > dont think > Sent: Thursday, February 27, 2003 4:28 PM > To: 'Bruce Richardson'; squ...@li...; > squ...@li... > Cc: da...@dm... > Subject: RE: [SM-PLUGINS] Suggestion: a compatibility plugin > > As promised, here is a first cut at a compatibility plugin. I think it > came out fairly clean and will indeed cut down on function duplication > and help retain plugin compatibility across most SM versions in wide > use. > > There are instructions and examples on how to use it in the README file > (as well as a sample of how to change your plugin's setup.php into the > recommended format to help SM be the fastest, best webmail around!). > > The attached autocomplete is a beta, but seems to be a good working > example of how to use the compatibility plugin... it works with most any > version of SM as is. > > What do people think? > > - paul > > > -----Original Message----- > > From: squ...@li... > > [mailto:squ...@li...] On Behalf Of > Bruce > > Richardson > > Sent: Thursday, February 27, 2003 3:00 AM > > To: squ...@li...; > > squ...@li... > > Cc: pdo...@ph...uce > > Subject: [SM-PLUGINS] Suggestion: a compatibility plugin > > > > I had a thought that might be helpful for plugins and (I think) for > the > > main SM code. I was looking at the code for the autocomplete plugin, > > where pdontthink has added functions to emulate sqextractGlobalVar etc > > to enable the plugin to be used with older versions of SM. It's a > good > > idea but if every plugin author does it then there's a lot of effort > > being duplicated. > > > > My idea is to create a Compatibility plugin, which could check the > version > > of SM being used and where necessary include files containing the > > missing functions. This would make it much easier to write plugins > that > > could be used by those still using SM 1.2.8 etc (and there are plenty, > > for various reasons): a plugin author could simply say "If you are > using > > an SM version earlier than X, you need the Compatibility plugin before > > this one will work". It wouldn't be hard to do a plugin that provided > > compatibility across 1.2.x and with a bit more thought plugins written > > for 1.4.x could be catered for. > > > > But I also think it could help the main SM code. There's a fair bit > of > > legacy emulation in the core code (e.g. creating the $_POST and > > $_SESSION arrays for older versions of PHP) which makes it larger and > a > > bit less readable than it would otherwise be. I think a lot of that > > might be moved into the Compatibility plugin. Not only would it > improve > > the readability of the main code, it would improve speed, since the > > legacy code need only be included when an older version of PHP is > > detected. The more recent versions of SM wouldn't need to enable the > > plugin at all and so even the checks would be skipped. > > > > If that second, more ambitious proposal were adopted, then the > > Compatibility plugin should become one of the core plugins in the > latest > > version of SM (whenever the plugin becomes a reality) and made > available > > as a separate plugin for older versions. Then the warning would be > "If > > you are using SM version earlier than X or PHP version earlier than Y, > > you will need the Compatibility plugin". > > > > Thoughts? > > > > -- > > Bruce > > > > The ice-caps are melting, tra-la-la-la. All the world is drowning, > > tra-la-la-la-la. -- Tiny Tim. |