[geeklog-devel] more GSoC project ideas
jmucchiello at yahoo.com
Thu Mar 3 23:23:13 EST 2011
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
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?
> 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),
> 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:
define('INCL_SEARCH',1); // yes, before the include, it is safe
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.
More information about the geeklog-devel