How deep the changes in the API should be?

14.8% 18
13.9% 17
13.9% 17
57.4% 70

122 Date 2009-04-20 03:09

Forums / Cotonti / Core Labs / Archive / Poll: Plugin API changes

123>>>

How far can we go?

Trustmaster
#1 2009-04-20 03:09
As you know new Module and Plugin APIs are planned for Renaissance. As for Modularization, I'm going to tell my opinion in its topic a little bit later, it is not really much we should do with the API, it's mostly about changing file structure.

In this topic I'd like to ask about Plugin API. We want plugins to be a little bit more flexible, hook into multiple places, etc. There is a really interesting idea of implementing plugins as event handlers and making a move towards event-driven behavior. But what worries me before I start to make API concepts is how far plugin developers are ready to go.

So I wonder how much backwards compatibility there should be. Here I explain poll options:
  • Brand new - the API is something revolutionary, but all the existing plugins will have to be rewritten. Almost no backwards compatibility at all.
  • Major upgrade - event-driven design, flexibility benefits. Will require changes in interface part of all the plugins, but the actual code will stay the same. It's about changing 10-30% of code in plugins.
  • Minor update - just try to add multiple hooks keeping current design. Will require changes in plugin headers (currently known as SED_BEGIN_EXTPLUGIN). 3-5% of changes in code and old plugins should work too.
  • No changes - just leave the plugins alone.

Please explain your choice, especially if you are a Team member.
May the Source be with you!
Elgan
#2 2009-04-20 04:38
do you have any more details on designs?

It would be nice, Im also thinking of some sort of setting auth functions as well as getting auth, as you have to grab authing for each new created user group.

admin needs to be more plugable if we want proper intergration, atm ive left all my admin in my plugin, as its easier, plus all my admin is in 1 section then. HOwever, its still seperate from the engine admin and i have to provide 2 admin links.

ive never actually needed to multiple hook, Its just easier to make a function if its code thats going to be duplicated.
Dayver
#3 2009-04-20 08:44
I voted for Major upgrade because from my point of view, this is the optimal ratio between the new opportunities that are provided and the complexity of changes to the old plug-ins
Pavlo Tkachenko aka Dayver
Trustmaster
#4 2009-04-20 14:16
Not very much information on designs unless we are pretty sure how much backwards compatibility we want.

Brand new - is likely to be new plugin abstracts, reviewing everything on what plugins are. I haven't thought what it could be. Just means that no old plugins will work at all.

Major upgrade is most likely to be based on callback functions. So every plugin part will be a function. You can bind it as a handler for several events at a time (aka hooks). When a module is run, it preloads plugin includes so all necessary callbacks are compiled and binded. A hook calls the callbacks due to their order. Most changes inside of the plugins are related to making them functions, meaning also that they will need to access global variables explicitly.

Minor update is about adding extra functionality without changing the concept of plugin parts (which will stay as includes). Just extend sed_plugins to bind the same part to several hooks, improve auth handling and implement a few other requested features. There still be changes in plugins, but most of old code will work.

I just want to warn that if you vote for "Brand new" or "Major upgrade" that would mean that old plugins will need some work. I'm not sure there will be enough enthusiasts to do it.
May the Source be with you!
aiwass
#5 2009-04-20 23:55
In my opinion, there are a few things that i think would be needed as standard parts of Cotonti, before any changes regarding API's etc.

Those things should be :
- Custommetas (The admin can set what keywords he wants on any pages, events, forums etc. he wants. SEO at it's best)
- Events & Calendar should not be a plugin, it should be standard.
- Trackbacks as well
- Related Pages (SeeAlso is a plugin today from LDU/Seditio)

When we talk about API's there should be a API that, at least in parts, work externally for other sites to integrate with your site (Ex. Youtube, Digg, SoundCloud, Facebook etc.). By thinking of this when work begins on designing an API for Cotonti, would make it more viable for future users and also be an incentive to plugin builders/module builders to create based on versatility.

If we go for Brand New, then the above stated would be made as standard, at least i think so. Maybe even go as far as stating that all todays plugins are standard features included and the API opens new doors and development concepts for integration and involvement of Cotonti based "Brand New"-Plugins.

I would even go as far to say that it might be the only way to separate from the old Seditio way of making, integrating and developing of new features, which is now translated over to Cotonti, as it is based upon Seditio-N.

Personally i would go for Brand New, since i love technology and smart new features, even though, those stated in the beginning are old as hell, but they serve a good purpose and they are standard parts of other CMS/Frameworks out there that are commitment/community driven projects.

Vote is BRAND NEW
Take all that money that we spend on weapons and defences each year and instead spend it feeding and clothing and educating the poor of the world, which it would many times over, not one human being excluded, and we could explore space, together, both inner and outer, forever, in peace. - Bill Hicks

https://evlear.com
Kort
#6 2009-04-20 23:56
There are just 37 plugs in the downloads/plugins. Why worry? Brand new.
SED.by - создание сайтов, разработка плагинов и тем для Котонти
Trustmaster
#7 2009-04-21 03:00
When I say API, I usually mean Application Programming Interface from Software Architect's or Software Designer's point of view. It's not FaceBook/GoogleMaps integration or whatsoever. Also please notice that in Cotonti we stake on modularity rather than built-in features and more freedom for third-party programmers.

There are 37 plugs here, but a hundred more inherited from Seditio here and there. Keep in mind we can loose em all. If it is ok, then Renaissance has a chance to be something different, whereas Genesis will stay for long-term backwards compatibility.
May the Source be with you!
esclkm
#8 2009-04-21 13:32
We need major upgrade or brand new.
But in Renaissance we need new stable concept, which must be not edited or rewritten in new versions.
If we will rewrite it in every version - our CMS will be not so attractive for developers
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
This post was edited by esclkm (2009-04-21 13:43, 14 years ago)
tensh
#9 2009-04-21 14:38
Is there anything wrong with the current plugin system?
What do you miss in this system?
Because if you want to change something that is working fine, there must be a strong reason to do so.

I agree that plugin API, if changed, must remain the same for a loooong tiiime.
Trustmaster
#10 2009-04-21 15:06
The poll is not over so continue voting, but I see that we're going to be pretty ready for almost any changes that would bring significant benefits.

Now it is time to start a research and learn what exactly we are going to change. So please request features you would like to see in Renaissance as a plugin developer. Our overall goal is to make plugin development as easy as possible, flexible to implement almost anything and still strong enough and bug-proof.

Then we discuss these features, select those worth implementing and after that form project details for the API upgrade.
May the Source be with you!
Lissbol
#11 2009-04-21 17:36
# esclkm : If we will rewrite it in every version - our CMS will be not so attractive for developers

agree with that if Cotonti is going to have a chance in the future vs. WP , Drupal etc etc then über major changes can't be made in every release.
LISSBOL Designs
Trustmaster
#12 2009-04-21 19:17
OK, here is a list of suggestions I have collected so far:
  1. Remove SED_EXTPLUGIN block from every single plugin file. In fact, it is more annoying and redundant rather than useful. "Code" is the same as plugin name. "Part" can be identified by file name. "Hooks" can be binded in setup file (see below). "Tags" are better to be collected they way "tpltags" plugin does it (by scanning the code instead of forcing plugin developer to describe every tag). "Order" can be specified in hook binding.
  2. Specify hook bindings as an array in setup file like:
    $hooks = array(
    	array('filename1', 'hook1', 10),
    	array('filename1', 'hook2'),
    	array('filename2', 'hook3', 99)
    );
    where the third optional parameter is priority (order). As you can see, it also allows for multiple hook bindings.
  3. Automatically preload plugin permissions into $usr['auth_read'], $usr['auth_write'] and $usr['isadmin'].
  4. Automatically preload plugin langfile.
  5. Already added in tickets: simplify CODE check. It can be
    defined('COT_CODE') or die('Wrong URL');
  6. Time to change sed_ to cot_

More brainstorming while writing a plugin:

7. Auth hooks. Add ability to affect auth in exact places (already known as EYOOP issue).

8. SQL query hooks. There are some important queries that a plugin developer would like to modify before they get executed. For example, if you want to affect forum posts order and join it with another table. Currently queries are executed like $sql = sed_sql_query("SELECT ..."), so the only way to change it is either a corehack or another similar query. If we did it like:
$query = "SELECT ...";
forums_posts_query(); // HOOK here
$sql = cot_query($query);
it could leave a possibility to edit the query with a plugin before it gets executed. It's not the most elegant way to modify a query, but if you know a better way, don't hesitate to share.
May the Source be with you!
This post was edited by Trustmaster (2009-07-15 04:28, 14 years ago)
esclkm
#13 2009-04-21 23:24
Agree at all. But I think (8) is unusefull
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Kilandor
#14 2009-04-22 01:00
I vote for Major Upgrade, new features, enhancments etc.

  • New hooking features, multi-hooking(same file multiple hooks), timer based hooks(ex, a cron sort of thing)
  • All configs, settings etc, should be code, not the commented crap(leave old method for backwards compatibility)
  • Advance install/uninstall API, IE on install before or after core install, it can be set, to code your own menu/options, or atleast flag options to come up, ex On install ask if they want to drop a SQL table and re-add it, or ask if they are upgrading, to run upgrade code, on uninstall ask if they want to drop it.
  • New functions that are friendly for Plugins, such as easy config change functions, etc
  • Prob more but i'm drawing a blank now.
urlkiller
#15 2009-04-22 02:09
i think a more developer friendly sql install should considerd as well as maybe upload packed plugins that get unpacked by the system. would make it far more manageble for the users after.

making a fresh start, heh! just shooting some ideas in the pool...

# maybe its cool to have a flexible config system. like a myplug.config.php that gets included auto. where you can define more and flexible new rules and settings for the plugin itself.

# more easy integration of the core features: tags, comments, ratings, textboxer etc. nice would be a cot_create_comments('bla','bla','bla'); on any of the functions.

# while working a lot with ajax its bad that always the whole page gets loaded. would it be possible to have special plugin functions for a second db conection for ajax content? or more like a build in ajax query on the db. where you can execute, edit, add entries?

# google apis java librarys!! can be defined in config and get's properly installed in <head>
i know jquery is there for me, but sometimes the jquery misses some of the kick other libs have...

# sql query injection sound a bit bad... i would like to see a more low -level programmer friendly sql query system. integrated and easier to understand left / right joins and etc.

query('table','field LIKE %BLALBA%','some more sql','ASC');

some sort of that, dont know. if you don't like its anyways cool for me.

# multihooking, cool!

# yeah, upload a rared archive and the system installs. no ftp crap anymore.

# auto chmodding of the files / folders. info from config file!?

# update function O_o cool would be if you had an external api connection where a file is checked if the installed version is still up to date. if the server is allowed he downloads the new file from server, if he's not allowed he simple announces that a new version is available. this would be very very helpfull in support and bugfixing because everyone would have the latest version. of course this would be a optional feature for very huge plugins. (iam talking here about how hard it was to keep track on every single usergal release.)

# quick question. we are not only talking about the installation syste here. in short we're talking about making the developer / designer API more aprehensive for any type of developer. if we would had a sort of toolbox like in most other distributions we would interest more low -level and high -level programmers to develop for cotonti, thus makes us more noticed...
to be true first i was missing the huge documentations on seditio but then after some days of code browsing i was thinking that this is some sort of very stable and reliable system. i was missing most of the integrated features from other systems, wich, of course made them more complicated. but what aout haveing cotonti offering a broad array of predefined tools.

not only this will help develop a new type of plugin. if its easy to code more plugins will be made. more ideas will flow into the project. the more recognised it will be.

ok that would be enough for today. maybe i got some more ideas. dont' start coding yet ;)
URL shortener: <a href="http://bbm.li/!7AD5C7">http://bbm.li/!7AD5C7</a>

123>>>