[geeklog-devel] more GSoC project ideas

[cordiste]

Joe,

> Ben said he was going to put in my change
to allow "alternate" template engines.

Did I say something like that... because I don't remember...

Thanks,

Ben

2011/3/4 Joe Mucchiello <jmucchiello at yahoo.com>:
> 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.
>
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>