[geeklog-devel] more GSoC project ideas

[Joe Mucchiello]

The database idea is either too big or a little small depending on how you do 
it. I think the easy (and perhaps too small) way is to just make a PDO.class.php 
in the databases directory and use that to handle "legacy" database access. Then 
expose the PDO connection object as a global so new code can code against PDO 
directly. The GSOC part would be ensuring the legacy code works through PDO with 
as little change as possible. By the time the GSOC code was plugged into core, 
core would no longer support PHP4 (PDO is PHP5 only).

> On a similar topic, we could look at a GSOC program to change up our
> template library. It's a bit silly that we still don't have compiled
> templates (to the detriment of our performance). Joe's work could be used
> as a basis or the student could look at implementing an existing template
> library (preferably one that could be backward compatible with existing
> templates).

Or you could just ask me to write it. Ben said he was going to put in my change 
to allow "alternate" template engines. Once that gets in, I promised to release 
a plugin containing my template library. The current version on my harddrive 
contain IF/ELSE processing, LOOPs over arrays and database, better block 
handling, fully backward compatible with the phplib library, and can be cached 
to disk or memcache (although I need to reinstall memcache since my last 
computer rebuild). Oh, it also has a test suite.

> These might both be too big for a GSOC project, but worth thinking about?

Most likely.

> Finally, many may not remember, but years and years ago (2002 or 2003) I
> pushed a big set of patches to improve page load performance. If I recall
> correctly, I eliminated (through combination or caching) a bunch of SQL
> queries, cleaned up PHP code (including getting rid of some recursion),
> and
> completely rewrote the comment display code. Doing something similar again
> today as a GSOC project could be beneficial to Geeklog. I hadn't brought
> this up before because this is an awfully non-specific task. I'm not sure
> it will fit well all that well into GSOC project. Any thoughts?

And I did the same thing 2007. I still have a bunch of diffs I like to apply to 
lib-security and lib-common because it hits the database far too many times. I 
tried to sneak a couple of those into the socnet changes that still aren't 
released. If I thought the patches would be applied, I'd make feature requests 
and post patches. But since there's no track record there, I don't do it.

Want to reduce Geeklog's memory footprint? Compartmentalize the core functions:

In public_html/search.php:
define('INCL_SEARCH',1); // yes, before the include, it is safe
include 'lib-common.php';

In every plugin/function.inc:
if (defined('INCL_SEARCH')) include $plugin_path . 'search.inc';

And in search.inc, each plugin puts all the search related plugin_ functions.

Repeat this for most of the global php files: comment, search, user, 
usersettings, stats!!, submit, trackback/pingback,  etc. and you will reduce the 
load time of all pages.

I've also been working on lib-smallcommon. A drop-in replacement for lib-common 
that can be used in AJAX calls that don't need most of the COM_ library. The 
code is just sitting on my hard drive since Geeklog 1.4.1 going out of date. 
Geeklog is not a good foundation for "web 2.0" apps as it loads the moon to 
deliver cosmic motes.