So far I have 2 proposals for Genoa enthusiasts:

1. Join the team to continue the Genoa branch development.
2. Suggest improvements that would make Siena more friendly to you.

1. I pass... My ideas about how it should all work are different then yours.
   
   I am very old school and I take everything out what is not usefull ( call my programming lean ! )
   And if I were to start on the Genoa core I would make the gap between Genoa and Siena bigger in stead off smaller.
   (e.g. I would introduce a cache system other then yours).
   Also it is not benefitial to Cotonti as a whole... because the need to go to Siena will be smaller.. and thats not good.
   
   
    
2. Yes sure
   
   Since you are allready creating overhead, why not add wrapper classes for readability and ease off use ?
   http://www.google.nl/?q=pdo+wrapper+clas
   
   I saw some usefull ideas... I think PDO is the most likely to benefit from wrappers...

I Hope this is usefull ?

• Core modules (forums etc.) moved from /system to /modules - more about directory structure
• Siena has 'modules' and 'plugins', which together are called 'extensions'. They have the same structure and functionality, but modules are usually stand-alone pages, while plugins are used to enhance existing functionality (core, modules or other plugins).
• Siena uses PDO, which means SQL queries are done using $db->query() instead of sed_sql_query(). - more about the database layer
• Siena supports caching (10x faster pageload), but this is optional. - more about caching
• Siena has install.php, which automates a lot of the installation and upgrade procedure (also for extensions).
• Siena uses index.php as entry point for (almost) all requests. This means modules do not need their own file in root. Existing files are kept for backwards compatibility (e.g. plug.php). Extensions are now called using index.php?e=myext
• Siena has several collections of helper functions which we call APIs. They are the files in /system and include forms, caching, file uploads and extrafields. I especially like the Forms API, which makes extension development a lot easier. - some API documentation here (needs to be improved)

If you want to have a look at the Siena directory structure and files without having to download and extract the package, have a look on Github.

@Kingsley: It's no problem if you're not a pro developer, I once started as a newbie too. As long as you're enthousiastic about it, have no problem spending your time on it and you want to learn this stuff, you'll be ok. Trustmaster and I are here to help you if you have questions.

then i maybe have some suggestions. for now, all that is just a big questionmark for me...

1. Join the team to continue the Genoa branch development.
2. Suggest improvements that would make Siena more friendly to you.

I don't think we should scratch PDO, I'd prefer providing wrapper procedures in sed_sql_* style. This way we get rid of the dilemma of MySQL PHP extensions (there are currently 3 of them: mysql, mysqli and mysqlnd; a choice between them is not trivial and is host-dependent) and also save PDO benefits for those who really want to use PDO.

As for prefixes, it isn't really such a waste of time. It's the easiest thing in plugin conversion really, because it can be done in 2 clicks with an editor which has "find and replace in files" function or with CDT.

So, rather than backporting big things like i18n and caching from Siena to Genoa, I'd like to make Siena more friendly to Genoa developers. I didn't dedicate enough much time to it before, but now that we know that it is necessary, I can significantly improve compatibility. So far this would include the following goals:

• Add support for Genoa/Seditio plugins by default. Surely not all of them will work, but I think 80% is a reasonable part.
• Provide procedural database API.
• Relaunch TPL tags database.

If you think that it is a good idea, we can find other drawbacks in Siena and add more goals to this list and then add it to our roadmap on Github.

About the sed_ thing.... Personally i dont care about how a function is called.. I think we even should leave that alone (let it be sed... so what)
let me say it like this.... Does this change from sed_ to cot_ make anything better.... the answer is simply NO.
It takes a lot off time to do that.... custom plugs are not working anymore unless we use crappy fix layers for just renaming functions...
And that only because it sounds nice... i simply say if it is a waste of valueable time... dont do it !

Same rule applies for every change.... Does the spent time really make it better... if not dont do it.

I really hope to see the next generation Genoa rise...

I think it would be good for Cotonti to make a decision about procedural vs objectoriented and stick with it, and although I personally prefer OO code, I'm in favor of procedural code for Cotonti. This is for several reasons:

• Having a mostly procedural but very structured codebase makes the system easy to use and modify for beginners.
• We can use the slogan 'procedural where possible, object oriented where necessary' as a marketing feat. I think the simplicity of the code is an important benefit we have over Wordpress and the likes.
• Historically we've had a procedural codebase, it's too big a change to go all OO. We'd lose a lot of users that way.

I'm not saying it should all be procedural. XTemplate has always been OO and that doesn't bother anyone. I think it's ok to write core APIs in an OO way if procedural just doesn't make sense. In the end we should focus on speed, ease of use and readability. XTemplate and Caching are two examples of features that must be OO to make any sense. As for CotDB, I'm happy to go back to sed_sql_queries, although it should be extended with some conveniences we have in PDO (but procedural). Perhaps we can move PDO into a plugin so advanced users can still use it.

On a final note, I don't see us scratching Siena itself. Probably we'll try to make it more backwards compatible with Genoa and go on with Siena. This is simply because Siena has a lot of minor improvements and fixes as well, which are not quickly backported. It would be like throwing away 2 years of work.

what i LIKE would be the possibility to customize the siena system as you wish. some kind of "system-modules" that would allow me to add or delete internal parts as i wish in no time. i want forum -> i add forums module in /system/, i dont need that -> i delete the folder in /system/

so for a small site i would just have a system with 100KB and insane speeds because it only loads exactly the stuff i need/want.

Well, this is exactly what Siena's "modules" stands for. You can completely remove "forums" or "polls" for example just like you do with plugins. Or write your own module. This was called "Modularization" and it is a good example of the price that we had to pay for a new major feature, because in order to achieve it we had to do the following:

• Change directory structure and unify it.
• Modify the internals of site configuration system and build a configuration API.
• Modify the internals of site authorization system and build an authorization API.
• Unify the way plugins and modules are handled by the system and build an extensions API.
• Develop universal methods for installation/uninstallation and updating of modules and plugins.
• Move a lot of stuff from the core to modules which actually use it.
• Introduce such thing as dependencies between modules and plugins.
• Add cot_incfile() function which simplifies inclusion of one extension within another.

I'm sure I have forgotten some other things we had to do to achieve what we have now: you can assemble your site of modules and plugins like of lego bricks. But as a result it is not backwards compatible, it's a big bang.

There are some unpopular decisions we've made without being enforced to. ez mentioned one of them, CotDB / PDO. A funny thing is that it was actually aimed at developers new to Cotonti, because in the modern world of PHP5 adoption, PDO library is very common and is used by lots of programmers around the world. It is also the basement of such popular libraries as Doctrine and phpActiveRecord. So it is likely to be more familiar for a newcoming PHP programmer rather than sed_sql_* functions.

I think the most unreasonable change technically speaking is the global change of prefixes from sed_ to cot_. We could easily live without that. But it's a kind of marketing thing, it's about project recognition. If you are new to Cotonti and start looking at the code, one of the first questions which appear is "This system is called Cotonti, why does everything start with sed_?".

Now back to Genoa and new features. Cache is another good example. In Siena we are developing a more advanced cache subsystem. It consists of several layers of caching, from caching particular variables to caching entire pages. All sounds very good in theory, why not apply it to Genoa fresh out of the oven? Well, it would break it then. It took a few releases in development branch to get it stable enough. Currently it is still several steps from being complete.

For about 1.5 years we actually used Siena as a laboratory for new features which then were backported to Genoa. It worked until these branches became so different that I got tired of backporting and also that topic of "stop making changes in Genoa" appeared. If there were people dedicated to Genoa branch, the process of getting new features in Genoa would be easier.

i can fully understand that its hard to maintan two releases with a short staff and not so many active useres contributing.

But i feel that Siena gets kinda packed with stuff i maybe never need for a project.
So i for my part always choose the genoa branch and then build the features i need with plugins.
this is working smoothly and perfectly for me. sure i invested a lot of time for doing the work
and it maybe faster but i like it to have a rough frame and add features to it with modules.

i choose that system because its not just another wordpr**s, jo**la... and its quick, fast and nice to modify to your needs. IF you really need that.
although i would like to see features like caching and modern stuff that dont changes the interal syntax too much but make the system faster.

dont get me wrong here. i still dont want the old system to change that much but for me its important that existing stuff like hooks, plugin syntax and skin syntax stays the same. iam open to any "addition" if its not touching these stuff.
-----------------------------

what i LIKE would be the possibility to customize the siena system as you wish. some kind of "system-modules" that would allow me to add or delete internal parts as i wish in no time. i want forum -> i add forums module in /system/, i dont need that -> i delete the folder in /system/

so for a small site i would just have a system with 100KB and insane speeds because it only loads exactly the stuff i need/want.

ok just my 2 cents...

OTHER THAN THAT! I STILL LOVE THAT PROJECT!! AND KEEP UP YOUR INSANE GREAT WORK FOR NO F* PAYMENT GUYS!

http://s3.amazonaws.com/kym-assets/photos/images/original/000/000/578/1234931504682.jpg

• This projects has been around for 3 years.
• Siena in particular has been in progress for 2 years.
• We stopped making major changes in Genoa a year ago.
• Genoa support will be continued as long as there are sites demanding it.
• Siena is mostly aimed at new projects and tries to follow modern trends in web development.
• Genoa is aimed at long-existing sites which follow the LDU/Seditio path.
• We don't enforce migration from Genoa to Siena unless it is really necessary or beneficial.

There is an important and contradictory thing about Genoa: users request changes and no changes at the same time. We got many complaints that there are too many Genoa releases (about 15 by then, 21 by now) and we should better stop changing it and leave the plugin and skin developers some space to breathe. We did, we left the core alone and let the plugin and skin developers do what they want knowing that the core doesn't change. Now there are complaints that there are no new features in the Genoa's core. But keep in mind: if there are new features, it will probably require changes in plugins and skins.

Probably I was not clear in my previous post so I'll say it in other words: if there are people who want to continue developing the Genoa core, we'd be glad to delegate Genoa branch maintenance to them. The only requirement is that they should use the official Git repository to develop it and be careful with compatibility between releases.

Once again, we have no intention to cancel the Genoa branch. We even plan to release more Genoa plugins because we continue developing them for sites running Genoa and having no benefits to upgrade to Siena.

It's understandable to keep things simple, and gradually improve the core; however, the Siena branch has been around for quite some time now providing ample time to update plugins and themes. Most of the plugins people are requesting are included in the default package of the Siena branch (or achievable quite easily), and even then.. developing plugins for Siena is not that different from Geona.

To try and keep Cotonti from moving to object oriented code is silly; It is the future, and the next best thing. I don't seem to understand why it will shy away php programmers from Cotonti. Realistically any new comer to Cotonti is going to have to invest a good amount time learning how it is structured. The first time I looked at Wordpress.. I was completely lost, but any good programmer will pick it up in time.

The only underlying problem I am finding with the Siena branch is the lack of theme developers. Which it can be hard to find willing, and skilled, template designers/coders. I personally find both Siena themes extremely unattractive, and even more so the Geona themes.

There are few things you might consider..

A lot of members just converted (1 yr ago) to Genoa, and now another big change is on the way. And you basically say that Genoa is stopping.
This is at least, for me, not very motivating... (I wonder how many ppl are still on SED because of plugins they cannot convert?)

Cotonti is a really small community, and core developers are less then 5 (3 ?).
If you make the core and also other parts harder to read with all sorts off classes and OO code, new unexperienced developers will soon get
lost in the classes, I am a developer with 25 yrs experience, and believe me i have seen it all and done it all in a lot off languages (yes.. also OO).
Dont get me wrong here, OO is really a good concept !, but it can be hard to get.
That brings me to the reason WHY i am using Cotonti Genoa: I can follow every bit in the code without any knowledge (That's AWESOME).

Back to the developers part: If you want new ppl to start working on the core or plugins, make it easier.
Second thing: If the lives of the core devs change (kids, mariage, demanding job whatever) then impact will be great on Cotonti, so thats why
Cotonti needs new devs !!!

One example in the new features:
The database layer... i think i know the reason why devs put that in... to be more independant from the database we use.
So we can put in MS-SQL or something.  (At least thats what i can make up from reading a little bit about it).
I think this is strange, considering 99,5 % will use MySql anyway. WHY o WHY waste time on 0.5%... ?? (just to have a cool abstract layer.. ?? )

I think that Cotonti is better of if we have much more nice plugins / features, and good tutorials for new users.
And I truly believe that Cotonti is helped much more if the core changes are done much more gradual... and not those BIG bangs you are doing now.

Well big story.. but I truly believe this.. 

Conclusion:
Keep it simple and no BIG bangs.. and more front end things (cool plugs.. like good FB stuff).
And improvement of the core, can be done slowly.

It seems I started a discussion here, and these are just my thoughts... but I am asking everybody to participate in this discussion.

you already have one user :) up till today i find Sienna meh.. to much change... for the change? I dunno, but most implemented things are for the real developer, while userfriendlyness is kinda going out of the window.

before cotonti programmers jumping onto me and giving 1000s of reasons why sienna is better.. I am a user, and experience it the way I discrib above. Just an objective assessment, that's all.

In the Cotonti Team we don't have an explicit intention to halt the Genoa branch and force everyone to Siena migration. But we are a very few people in fact and we've made our choice in favor of Siena.

I don't mind if somebody continued the development of Genoa branch. But there is one major requirement: it must be absolutely backwards compatible with previous Genoa releases (i.e. it must not require any changes in plugins or templates and it must not break any existing sites).

E.g. I see:  CoTemplate 2.7, Jquery 1.71
Those are not difficult things to put in 0.6.21....

I have looked at Siena (internal coding) and I have seen some changes that are, for me, NOT an improvement.. (well thats just me I guess, I like it simple).
I thought all the classes and the database layer class is not making the code more easier to read unless you really dive into it or know it.
(Dont get me wrong here, i think OO is a great .... BUT there is a big disadvantage as well), all this class stuff is making it harder to read, find, adjust the core code...
(Well the 3 or 4 core developers are going to kill me having said this... but i see what you are trying to do... and they try real hard.. so no flame intended..)
 

Back to Genoa >  Q: Is Genoa getting improved Yes or No.