Cotonti / Open Source PHP Content Management FrameworkContent Management Framework

How should Cotonti 0.9.x connect compatibility layer for 0.6.x plugins?

33.3% 5
66.7% 10
0% 0

15 Datum 16. August 2010, 17:27

Foren / Cotonti / Core Labs / Archive / Umfrage: Old plugins compatibility layer in Siena

Implementation details

#1 16. August 2010, 17:27
I have already responded to some fears of loosing all the plugins and existing modifications with the 0.9.0 release:
# Trustmaster : A few things to make Siena gossips more clear:
  1. Yes, there will be changes for plugin and module developers. New APIs, new abilities, some refactoring.
  2. In most cases, converting a plugin from 0.6 to 0.9 is a matter of 15-60 minutes.
  3. There will be an ability to run old plugins through a compatibility layer which provides old functions and some old behavior.
  4. When 0.9.0 will be released, it still will be marked as unstable. For use on production sites we will still recommend Genoa, so 0.6.x will be supported at least until Siena becomes very stable (which may happen by 1.0). By that time we will solve all such problems as lack of documentation, plugins and critical bugs.

In this topic I'd like to know your opinion about how the compatibility layer should be switched on in Siena.

The compatibility layer provides the API most of 0.6.x plugins are used to and makes it possible to install and run such plugins on a 0.9.x site. Technically it's a huge include file containing obsolete functions (which are no longer used in 0.9) and function aliases (because function prefixes will be changed soon) and some tweaks in plugin management and other parts to provide expected behavior.

There are 3 options of connecting this layer, each has its benefits and drawbacks (read below).

Automatic - in this case Cotonti will remember which plugins use the old API and try to connect the compatibility layer every time a part of such plugin is hooked/invoked.
+: everything is done by the engine, administrator may even not know that he's running obsolete plugins. Also the layer is not connected when no 0.6 plugins are invoked.
-: connecting the layer is a performance loss itself, also the automatic connection code is much more difficult than manual and may affect the performance itself.

Manual - if you use obsolete plugins on your site, just switch the compatibility layer on in the Admin CP and it will be used on entire site.
+: much easier to implement than automatic. Better performance when the layer is actually used (less time connecting).
-: the layer will be also connected for requests with no 0.6 plugins invoked.

Always on - old functions are always available.
+: nothing to switch on or off.
-: the worst performance of all as it hits sites running no 0.6 plugins at all. Also may cause plugin developers to slack too much and not wish to try 0.9 benefits at all.
May the Source be with you!
#2 16. August 2010, 17:59
I guess this is the best solution:
Manually for entire site (switched on by admin)

But can it be done that IF you do an upgrade
- or: this is set to ON for all installed plugins.
- or: all plugins are disabled and you have to put it on manualy.

just to avoid a lot of problems during upgrade.
Maybe put this in the upgrade-script.

This is just an idea.
... can we help you ...
#3 16. August 2010, 19:13
This setting can be automatically switched on when installing old plugins and when upgrading from genoa (nice point, thanks).
May the Source be with you!
#4 16. August 2010, 20:56
Imho Siena could be a good milestone to discard most current Cotonti plugins, for most of them are not made properly, do not function properly, are not supported and are basically old-type Seditio stuff brought into Cotonti as is without using its advanced plugin facilities.
As you rightfully noticed, upgrading a plugin to the Siena standard takes absolutely reasonable 15-60 minutes. So any adequately thinking plugin maker can easily add another half an hour (@ most) to add Cotonti-specific features (i.e. autoinstaller), check for the available functions that can reduce the plugin code & review the code in general, fillout technical info (version #, date, author) and at least test it over again to make sure it runs. This way we could, after sometime, have an ordered repository of proven plugins and filter off the useless rubbish.
I know that this could be a radical offer, but what are we gonna lose? The plugins that do not work anyway? Maybe DonP would ultimately switch over to a different CMS. Otherwise starting from scratch would only bring benefits, clean code, stable & usable modules. And, ultimately, some fresh blood.
My vote is NEITHER. - создание сайтов, разработка плагинов и тем для Котонти
#5 16. August 2010, 21:20
No Capability!
I think we need only - FAQ for converting plugings, nothing more.

Or Capability plugin - witch user can install - to use all old functions - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
#6 16. August 2010, 21:33
Kort, I can follow you too. But not everybody has the knowledge to convert the plugins themselve.

If the original pluginmaker is not willing to invest some time in the plugin, or you can't find someone to do the convert. Your site will be offline, or doesn't have the full behavior as before.

I see it only as a transfer time. Maybe have this ability in 0.9 but not on 1.0. But this give us, not plugin-builders time to do or ask to do the convertions of the needed plugins.
... can we help you ...
#7 16. August 2010, 22:23
Agreed with pieter. And I think we'll drop old plugins and old functions when 1.0 comes (most of necessary plugins will have been converted to the new APIs by that time).
May the Source be with you!
#8 16. August 2010, 22:47
We are talking about funny things here. First off, some plugins are used where xtemplate can easily take over. Other plugins just rest in the downloads area with comments asking for fixes. For some of them decent replacements have been made. What is left now is maybe 10-15 things that need facelifting. So rather than submitting requests for developers to maintain compatibility, wouldn't it be easier to fix them? And maybe Siena would be released faster. - создание сайтов, разработка плагинов и тем для Котонти
#9 16. August 2010, 22:56
That is also a good option.

How lang does it take to make the compatibility?
Maybe invest this time in plugin conversions.
... can we help you ...
#10 16. August 2010, 23:12
There is nothing yet to provide compatibility with. Let's just make a list of plugins first. Then we could try to communicate with some of the 19 plugin makers who could do the job. Then we'll think what to do next. - создание сайтов, разработка плагинов и тем для Котонти
#11 17. August 2010, 00:50
We first need to know the conversion actions.
Then we can say something usefull about conversion, so I will wait for the specs.

I believe in this case for a big bang, we must not stick to the old ways IF the new way has more advantages. But i agree on a compatability mode for 0.9..
==- I say: Keep it EZ -==
#12 23. August 2010, 19:01
is there any type of roadmap of changes that be made?
would be very cool to know WHAT EXACTLY changes in the API.

i can only think of changing function names, changing var names and some other additions that not really affects the current plugins. Maybe some changes in the DB Tables too...
So if there are only functions, vars, etc. that need some sort of campatibility isn't it possbile to just let the plugin devs some files where all "old" functions & vars in it that they could include if they wish....


the conversion of plugins will maybe fast but also a little pain in the ass because you have to search/replace everything (again).

If we take a look in the current plugins we'll see that most plugs consists of only a few lines of code. most plugins work with under 1000 lines of code so there isn't so much to do.
URL shortener: <a href="!7AD5C7">!7AD5C7</a>