From tony at tonybibbs.com  Sun Oct  5 19:07:32 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Sun, 05 Oct 2003 18:07:32 -0500
Subject: [geeklog-devel] Last login needed?
Message-ID: <3F80A434.2050604@tonybibbs.com>

As I sit here my site is now approaching 3000 members.  While this would 
  normally be a big feat, fact is that many accounts are not active.  I 
was thinking it would be nice to start tracking the last login.  The 
reason I say that is there are a number of accounts I could probably 
remove in the interest of saving space.

That being said, would anybody else find this useful?  My thought is 
that we would add two new config settings, $_CONF['purge_accounts'] 
which is either true or false and $_CONF['purge_thresold'] which would 
be the number of days since last login before the account would be 
removed.  Of course a few days ahead of time I'd like to see an email go 
out to warn the user that this is happening.

Thoughts?  Questions?

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From dirk at haun-online.de  Mon Oct  6 01:57:48 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 6 Oct 2003 07:57:48 +0200
Subject: [geeklog-devel] Last login needed?
In-Reply-To: <3F80A434.2050604@tonybibbs.com>
References: <3F80A434.2050604@tonybibbs.com>
Message-ID: <20031006055748.22703@smtp.haun-online.de>

Tony Bibbs <tony at tonybibbs.com> wrote:

>I was thinking it would be nice to start tracking the last login.

/me shakes head

from docs/history:
|- Added tracking of users lastlogin to the userinfo table.
|  New $_CONF['lastlogin'] added to config.php - SESSION SETTINGS area    

That's already there in 1.3.8 ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From tony at tonybibbs.com  Mon Oct  6 08:55:23 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 06 Oct 2003 07:55:23 -0500
Subject: [geeklog-devel] Last login needed?
In-Reply-To: <20031006055748.22703@smtp.haun-online.de>
References: <3F80A434.2050604@tonybibbs.com> <20031006055748.22703@smtp.haun-online.de>
Message-ID: <3F81663B.1060201@tonybibbs.com>

Ok, that still leaves the crux of the problem which is automating the 
purging of the accounts.  My bad on not seeing the field added.

My hunch is over 40% of my accounts could be purged.

--Tony

Dirk Haun wrote:
> Tony Bibbs <tony at tonybibbs.com> wrote:
> 
> 
>>I was thinking it would be nice to start tracking the last login.
> 
> 
> /me shakes head
> 
> from docs/history:
> |- Added tracking of users lastlogin to the userinfo table.
> |  New $_CONF['lastlogin'] added to config.php - SESSION SETTINGS area    
> 
> That's already there in 1.3.8 ...
> 
> bye, Dirk
> 
> 

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tony at tonybibbs.com  Tue Oct  7 21:58:28 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 07 Oct 2003 20:58:28 -0500
Subject: [geeklog-devel] Problems with setcookie() in 1.3.8-1
Message-ID: <3F836F44.9030105@tonybibbs.com>

This simply does not work for me:

setcookie ($_CONF['cookie_session'], '', time() - 10000,
                $_CONF['cookie_path'], $_CONF['cookiedomain'],
                $_CONF['cookiesecure']);
setcookie ($_CONF['cookie_name'], '', time() - 10000, 			
		$_CONF['cookie_path'],
  		$_CONF['cookiedomain'],
		$_CONF['cookiesecure']);

This does:

setcookie($_CONF['cookie_session'],'',time()-10000,$_CONF['cookie_path']);
setcookie($_CONF['cookie_name'],'',time()-10000,$_CONF['cookie_path']);

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From tony at tonybibbs.com  Tue Oct  7 22:01:40 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 07 Oct 2003 21:01:40 -0500
Subject: [geeklog-devel] [Fwd: Problems with setcookie() in 1.3.8-1]
Message-ID: <3F837004.9010505@tonybibbs.com>

Nevermind, neither seem to work.

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+
-------------- next part --------------
An embedded message was scrubbed...
From: Tony Bibbs <tony at tonybibbs.com>
Subject: Problems with setcookie() in 1.3.8-1
Date: Tue, 07 Oct 2003 20:58:28 -0500
Size: 1441
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20031007/f1e43df7/attachment.mht>

From tony at tonybibbs.com  Tue Oct  7 22:09:58 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 07 Oct 2003 21:09:58 -0500
Subject: [geeklog-devel] Re: [Fwd: Problems with setcookie() in 1.3.8-1]
In-Reply-To: <3F837004.9010505@tonybibbs.com>
References: <3F837004.9010505@tonybibbs.com>
Message-ID: <3F8371F6.2050909@tonybibbs.com>

Ok, no clue as to why I can't log out of my site.  Any thoughts are 
appreciated.

--Tony

Tony Bibbs wrote:

> Nevermind, neither seem to work.
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Problems with setcookie() in 1.3.8-1
> From:
> Tony Bibbs <tony at tonybibbs.com>
> Date:
> Tue, 07 Oct 2003 20:58:28 -0500
> To:
> Geeklog <geeklog-devel at lists.geeklog.net>
> 
> 
> This simply does not work for me:
> 
> setcookie ($_CONF['cookie_session'], '', time() - 10000,
>                $_CONF['cookie_path'], $_CONF['cookiedomain'],
>                $_CONF['cookiesecure']);
> setcookie ($_CONF['cookie_name'], '', time() - 10000,            
>         $_CONF['cookie_path'],
>          $_CONF['cookiedomain'],
>         $_CONF['cookiesecure']);
> 
> This does:
> 
> setcookie($_CONF['cookie_session'],'',time()-10000,$_CONF['cookie_path']);
> setcookie($_CONF['cookie_name'],'',time()-10000,$_CONF['cookie_path']);
> 


-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From tony at tonybibbs.com  Tue Oct  7 22:15:50 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 07 Oct 2003 21:15:50 -0500
Subject: [geeklog-devel] Re: [Fwd: Problems with setcookie() in 1.3.8-1]
In-Reply-To: <3F8371F6.2050909@tonybibbs.com>
References: <3F837004.9010505@tonybibbs.com> <3F8371F6.2050909@tonybibbs.com>
Message-ID: <3F837356.3030205@tonybibbs.com>

Had to set, for the first time ever, cookie domain to .iowaoutdoors.org. 
    No clue if this is because of changes to Mozilla or not.  Anyway, it 
works in mozilla and IE.  Not sure wtf makes such a big difference.

--Tony

Tony Bibbs wrote:

> Ok, no clue as to why I can't log out of my site.  Any thoughts are 
> appreciated.
> 
> --Tony
> 
> Tony Bibbs wrote:
> 
>> Nevermind, neither seem to work.
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Problems with setcookie() in 1.3.8-1
>> From:
>> Tony Bibbs <tony at tonybibbs.com>
>> Date:
>> Tue, 07 Oct 2003 20:58:28 -0500
>> To:
>> Geeklog <geeklog-devel at lists.geeklog.net>
>>
>>
>> This simply does not work for me:
>>
>> setcookie ($_CONF['cookie_session'], '', time() - 10000,
>>                $_CONF['cookie_path'], $_CONF['cookiedomain'],
>>                $_CONF['cookiesecure']);
>> setcookie ($_CONF['cookie_name'], '', time() - 10000,            
>>         $_CONF['cookie_path'],
>>          $_CONF['cookiedomain'],
>>         $_CONF['cookiesecure']);
>>
>> This does:
>>
>> setcookie($_CONF['cookie_session'],'',time()-10000,$_CONF['cookie_path']); 
>>
>> setcookie($_CONF['cookie_name'],'',time()-10000,$_CONF['cookie_path']);
>>
> 
> 


-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From dwight at trumbower.com  Tue Oct  7 23:15:40 2003
From: dwight at trumbower.com (Dwight Trumbower)
Date: Tue, 07 Oct 2003 22:15:40 -0500
Subject: [geeklog-devel] Re: [Fwd: Problems with setcookie() in
  1.3.8-1]
In-Reply-To: <3F837356.3030205@tonybibbs.com>
References: <3F8371F6.2050909@tonybibbs.com>
 <3F837004.9010505@tonybibbs.com>
 <3F8371F6.2050909@tonybibbs.com>
Message-ID: <6.0.0.9.0.20031007221423.01c73888@localhost>

Maybe because the cookie logic changed from 1.3.7 to 1.3.8.

At 09:15 PM 10/7/2003, you wrote:

>Had to set, for the first time ever, cookie domain to 
>.iowaoutdoors.org.    No clue if this is because of changes to Mozilla or 
>not.  Anyway, it works in mozilla and IE.  Not sure wtf makes such a big 
>difference.
>
>--Tony
>
>Tony Bibbs wrote:
>
>>Ok, no clue as to why I can't log out of my site.  Any thoughts are 
>>appreciated.
>>--Tony
>>Tony Bibbs wrote:
>>
>>>Nevermind, neither seem to work.
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>Subject:
>>>Problems with setcookie() in 1.3.8-1
>>>From:
>>>Tony Bibbs <tony at tonybibbs.com>
>>>Date:
>>>Tue, 07 Oct 2003 20:58:28 -0500
>>>To:
>>>Geeklog <geeklog-devel at lists.geeklog.net>
>>>
>>>
>>>This simply does not work for me:
>>>
>>>setcookie ($_CONF['cookie_session'], '', time() - 10000,
>>>                $_CONF['cookie_path'], $_CONF['cookiedomain'],
>>>                $_CONF['cookiesecure']);
>>>setcookie ($_CONF['cookie_name'], '', time() - 10000,
>>>         $_CONF['cookie_path'],
>>>          $_CONF['cookiedomain'],
>>>         $_CONF['cookiesecure']);
>>>
>>>This does:
>>>
>>>setcookie($_CONF['cookie_session'],'',time()-10000,$_CONF['cookie_path']);
>>>setcookie($_CONF['cookie_name'],'',time()-10000,$_CONF['cookie_path']);
>
>
>--
>+-------------------+--------------------------------------------------+
>|Tony Bibbs         |[R]egardless of what you may think of our penal   |
>|tony at tonybibbs.com |system, the fact is that every man in jail is one |
>|                   |less potential fisherman to clutter up your       |
>|                   |favorite pool or pond. --Ed Zern                  |
>+-------------------+--------------------------------------------------+
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
>

From robg at macosxhints.com  Wed Oct  8 07:37:05 2003
From: robg at macosxhints.com (Rob Griffiths)
Date: Wed, 8 Oct 2003 04:37:05 -0700
Subject: [geeklog-devel] Re: [Fwd: Problems with setcookie() in 1.3.8-1]
In-Reply-To: <3F837356.3030205@tonybibbs.com>
Message-ID: <BDDD588A-F983-11D7-AF88-003065BE20A8@macosxhints.com>

On Tuesday, October 7, 2003, at 07:15  PM, Tony Bibbs wrote:

> Had to set, for the first time ever, cookie domain to 
> .iowaoutdoors.org.    No clue if this is because of changes to Mozilla 
> or not.  Anyway, it works in mozilla and IE.  Not sure wtf makes such 
> a big difference.

Ah!  Thank you!  I hadn't been able to log out of my site using Safari 
for quite a while.  This simple little change made it possible again.

Is this documented anywhere?  It's not in the comments in config.php 
... seems sorta critical now, though.

Thanks Tony!
-rob.



From dirk at haun-online.de  Fri Oct 10 17:35:17 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 10 Oct 2003 23:35:17 +0200
Subject: [geeklog-devel] Plan for the weekend
Message-ID: <20031010213517.18264@smtp.haun-online.de>

I will be spending some time this weekend trying to address the (imagined
and real) issues that have been pointed out. It looks like a lot of
changes are needed all over the place, so chances that this could be
released as a patch for 1.3.8 are pretty slim. So the way to go will be
to integrate it all in 1.3.9. Depending on how things work out, there may
even be a surprise release of a 1.3.9rc1 (although I doubt it).

And for the records: Consider CVS closed for new features - bugfixes
only, please.


Tony mentioned the need to put some information up on geeklog.net,
pointing out that security is important to us, despite all claims to the
contrary.

>From our conversation on IRC:

<dhaun> we're really risking to lose a lot of credibility at the moment,
even if it's not exactly our fault and almost all of the exploits aren't
working
<IA-Outdoors> I hear you.  Maybe we should create a Security Section on gl.net
<IA-Outdoors> it would be a static page that goes through our stand on
it, how to report it as well as links to past exploits and their solutions?
<IA-Outdoors> that would go a long way to saying "hey, this stuff is
important to us too"

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From dirk at haun-online.de  Sat Oct 11 18:46:28 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 12 Oct 2003 00:46:28 +0200
Subject: [geeklog-devel] Plan B
In-Reply-To: <20031010213517.18264@smtp.haun-online.de>
References: <20031010213517.18264@smtp.haun-online.de>
Message-ID: <20031011224628.16059@smtp.haun-online.de>

Okay, since properly changing everything over to using COM_applyFilter
takes a lot longer than expected and since kses looks really promising,
I'm opting for a 1.3.8-1sr1 release tomorrow that would include

- kses, thus hopefully addressing all HTML / CSS / Javascript injection
scenarios once and for all
- the "don't show SQL errors in the browser" patch for the database class
- (not security-related) a fix to lib-sessions.php for when the cookie
domain is not set and the URL includes a port number
- and, possibly, a fix for an issue I seem to have found in
usersettings.php (need to double-check that first - more details then)

That would not address the issue when you're running MySQL 4.1, but I
guess we can ignore that for now (but include a warning). 1.3.9rc1, which
will address this, shouldn't be too far away ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From slord at marelina.com  Sun Oct 12 12:26:57 2003
From: slord at marelina.com (Simon Lord)
Date: Sun, 12 Oct 2003 12:26:57 -0400
Subject: [geeklog-devel] Last login needed?
In-Reply-To: <3F80A434.2050604@tonybibbs.com>
Message-ID: <E65FA53A-FCD0-11D7-B5A5-003065C030F2@marelina.com>

I just got back from my vacation and saw this thread.  I would *love*  
this feature.  For my needs I'd want to see a paginated output of  
people that have not logged in past X date and some options beside  
their listing like:

- delete account
- send member reminder of their account with link to page so they can  
delete or update the account (I see many people creating new accounts  
when they forget they have one or can't figure out how to get new pass  
info)
- place account on hold (IE, some people are assess and what I do to  
them is change their username but keep the account running, prevents  
them from using the same email... :)



On Sunday, October 5, 2003, at 07:07 PM, Tony Bibbs wrote:

> As I sit here my site is now approaching 3000 members.  While this  
> would  normally be a big feat, fact is that many accounts are not  
> active.  I was thinking it would be nice to start tracking the last  
> login.  The reason I say that is there are a number of accounts I  
> could probably remove in the interest of saving space.
>
> That being said, would anybody else find this useful?  My thought is  
> that we would add two new config settings, $_CONF['purge_accounts']  
> which is either true or false and $_CONF['purge_thresold'] which would  
> be the number of days since last login before the account would be  
> removed.  Of course a few days ahead of time I'd like to see an email  
> go out to warn the user that this is happening.
>
> Thoughts?  Questions?
>
> --  
> +------------------- 
> +--------------------------------------------------+
> |Tony Bibbs         |[R]egardless of what you may think of our penal    
> |
> |tony at tonybibbs.com |system, the fact is that every man in jail is one  
> |
> |                   |less potential fisherman to clutter up your        
> |
> |                   |favorite pool or pond. --Ed Zern                   
> |
> +------------------- 
> +--------------------------------------------------+
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
Sincerely,
Simon



From dirk at haun-online.de  Sun Oct 12 12:36:15 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 12 Oct 2003 18:36:15 +0200
Subject: [geeklog-devel] Last login needed?
In-Reply-To: <E65FA53A-FCD0-11D7-B5A5-003065C030F2@marelina.com>
References: <E65FA53A-FCD0-11D7-B5A5-003065C030F2@marelina.com>
Message-ID: <20031012163615.21967@smtp.haun-online.de>

Simon Lord <slord at marelina.com> wrote:

>I would *love* this feature.

I guess a lot of people would like to see a lot of very different options
for this. Now that the date of the last login is collected, why not write
a plugin that does it?

I agree that we need some improvements in the membership management, but
for experimenting which features actually make sense, a plugin would be
the best place, IMO. Once a certain set of features has been accepted, we
can still integrate it into Geeklog's core code.

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From dirk at haun-online.de  Sun Oct 12 16:25:29 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Sun, 12 Oct 2003 22:25:29 +0200
Subject: [geeklog-devel] Plan B
In-Reply-To: <20031011224628.16059@smtp.haun-online.de>
References: <20031011224628.16059@smtp.haun-online.de>
Message-ID: <20031012202530.25483@smtp.haun-online.de>

Oh, btw,

>- and, possibly, a fix for an issue I seem to have found in
>usersettings.php (need to double-check that first - more details then)

False alarm there. It could do with some more sanity checks, but there
isn't a problem. For a moment I thought it was possible to delete the
account for the anonymous user from the database.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From tony at tonybibbs.com  Fri Oct 17 17:26:29 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 17 Oct 2003 16:26:29 -0500
Subject: [geeklog-devel] Geeklog 2 Module API
Message-ID: <3F905E85.6030505@tonybibbs.com>

Vinny,

While I'm busting my a$$ to get the A&A stuff polished, I think you 
should take a stab at the module API for GL2.  Keep in mine with PHP5 we 
have the OO notion of an interface so what we need is to decide what our 
module interface will have in it for methods that modules will have to 
implement.  I think you can start but looking at 1.3.x in 
system/lib-plugins.php.  This won't take you a lot of time but I bet it 
will take us all 3 or 4 runs through before we iron it all out.

If you can take an initial stab at it and email it to geeklog-devel this 
weekend that would be great.  I cc'd the list in case anybody has some 
features they'd like to see in the API so they can contact you/us directly.

--Tony

+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From vmf at abtech.org  Mon Oct 20 02:29:41 2003
From: vmf at abtech.org (Vincent Furia)
Date: Mon, 20 Oct 2003 02:29:41 -0400
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <3F905E85.6030505@tonybibbs.com>
References: <3F905E85.6030505@tonybibbs.com>
Message-ID: <3F9380D5.8010500@abtech.org>

OK, here is a first go at the module/plugin API to get things started.  
I thought that I would start by recommending that plugins "register" 
themselves during install with geeklog, including whether they use the 
different plugin APIs (moderation, comments, ratings, search, etc) so as 
to eliminate the "doesXXXX" type functions that may be needed otherwise 
(should also make things more efficient when calling functions for 
multiple plugins).

In any case, please make lots of recommendations.  This doesn't really 
add much to what a plugin can do in GL 1.3.x, any new ideas would be 
very much appreciated.

-Vinny

<?php
interface glPlugin {
    /* installation functions */
    function install();                /* install the plugin */
    function uninstall();            /* uninstall the plugin */
    function upgrade();                /* upgrade the plugin from a 
previous version */
    function getVersion();            /* return plugin name and version 
(author(s)?, website?)*/

    /* user modifications */
    function onNewUser();            /* process new user */
    function onDeleteUser();        /* process user deletion */

    /* moderation */
    function getSubmissionForm();    /* return the form for plugin 
submission */
    function getModerationList();    /* return list of items for 
moderation */
    function onApproveSubmission();    /* process a submission approval */
    function onDeleteSubmission();    /* delete a submission */
    function onEditSubmission();    /* return the form to edit a 
submission */
    function getSubmissionCount();  /* return count of current 
submissions */

    /* search functions */
    function getSearchResults();    /* search items for keywords */
    function getSearchTypes();        /* return plugin search options */

    /* comment functions */
    function onCommentAction();        /* plugin action on comment 
submit, delete, etc */
    function getCommentParent();    /* for display of the parent above 
comments */

    /* ratings functions */
    function onRatingAction();        /* plugin action  on ratings 
actions (submit rating) */

    /* menu/display items */
    function getMenuItems();        /* return menu items related to the 
plugin */
    function getUserMenu();            /* return user menu options */
    function getAdminMenu();        /* return admin menu options */
    function getControlMenu();        /* return control menu options */
    function getCenterBlock();        /* return centerblock */

    /* profile */
    function getProfileBlock();        /* display plugin block profile 
values */
    function getEditProfileBlock();    /* return form to edit block 
profile values */
    function getProfileVar();        /* display plugin variable profile 
values */
    function getEditProfileVar();    /* return form to edit variable 
profile values */
    function saveProfileOptions();  /* save plugin profile options */

    /* export files (rdf feeds, ical files, etc) */
    function getExportNames();        /* return export file names the 
plugin uses */
    function getExportContent();    /* return export file content */
    function getExportCurrent();    /* return if exports are current */

    /* other */
    function getHeaderCode();        /* return plugin JS or Meta Data */
    function getStats();            /* return plugin stats information */
}



From tomw at pigstye.net  Mon Oct 20 09:25:03 2003
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 20 Oct 2003 13:25:03 +0000
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <3F9380D5.8010500@abtech.org>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org>
Message-ID: <20031020130127.M93970@pigstye.net>

Vinny, 

Looks like a good start!  Now some suggestions:  Along with the ability to 
register APIs at the start, it would be good to be able to register and 
unregister them after the plugin is installed.  That would allow the plugin 
writer to turn on and off such things as stats display from the interface 
easier.  The plugin could then make the appropriate calls to turn on any 
APIs it needed (the default being off) when it installs itself.  Thus you 
could have:

/* installation functions */
function install();                /* install the plugin */
function uninstall();            /* uninstall the plugin */
function upgrade();                /* upgrade the plugin from a previous 
version */
function regAPI();               /* register availability of API */
function unregAPI();             /* unregister availability of API */
function getVersion();            /* return plugin name and version (author
(s)?, website?)*/

instead of:

  /* installation functions */
  function install();                /* install the plugin */
  function uninstall();            /* uninstall the plugin */
  function upgrade();                /* upgrade the plugin from a previous 
version */
  function getVersion();            /* return plugin name and version author
(s)?, website?)*/


Some other thoughts.

What about the ability for a plugin to publish an API for other plugins to 
use.  A simple example: Blaines use of chatterblock functions in the forum.  
This might require you to further virtualize the plugin API so that the 
plugin could query the API interface in the same way the program itself does.

What about the ability to replace an internal Geeklog function?  This would 
allow the plugin to replace/enhance core Geeklog functionality. Of course 
this would require Geeklog to moderate, we would not want two plugins trying 
to replace the same Geeklog function.

Some of this may already be planned with the new modular structure, if so 
ignore me.

I would love to have the time to contribute more than suggestions, but at 
the present do not.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Vincent Furia <vmf at abtech.org>
To: Tony Bibbs <tony at tonybibbs.com>
Cc: Geeklog Development <geeklog-devel at lists.geeklog.net>
Sent: Mon, 20 Oct 2003 02:29:41 -0400
Subject: [geeklog-devel] Re: Geeklog 2 Module API

> OK, here is a first go at the module/plugin API to get things 
> started.  I thought that I would start by recommending that plugins 
> "register" themselves during install with geeklog, including whether 
> they use the different plugin APIs (moderation, comments, ratings, 
> search, etc) so as to eliminate the "doesXXXX" type functions that 
> may be needed otherwise 
> (should also make things more efficient when calling functions for 
> multiple plugins).
> 
> In any case, please make lots of recommendations.  This doesn't 
> really add much to what a plugin can do in GL 1.3.x, any new ideas 
> would be very much appreciated.
> 
> -Vinny
> 
> <?php
> interface glPlugin {
>     /* installation functions */
>     function install();                /* install the plugin */
>     function uninstall();            /* uninstall the plugin */
>     function upgrade();                /* upgrade the plugin from a 
> previous version */
>     function getVersion();            /* return plugin name and 
> version 
> (author(s)?, website?)*/
> 
>     /* user modifications */
>     function onNewUser();            /* process new user */
>     function onDeleteUser();        /* process user deletion */
> 
>     /* moderation */
>     function getSubmissionForm();    /* return the form for plugin 
> submission */
>     function getModerationList();    /* return list of items for 
> moderation */
>     function onApproveSubmission();    /* process a submission 
> approval */    function onDeleteSubmission();    /* delete a 
> submission */    function onEditSubmission();    /* return the form 
> to edit a submission */    function getSubmissionCount();  /* return 
> count of current submissions */
> 
>     /* search functions */
>     function getSearchResults();    /* search items for keywords */
>     function getSearchTypes();        /* return plugin search 
> options */
> 
>     /* comment functions */
>     function onCommentAction();        /* plugin action on comment 
> submit, delete, etc */
>     function getCommentParent();    /* for display of the parent 
> above comments */
> 
>     /* ratings functions */
>     function onRatingAction();        /* plugin action  on ratings 
> actions (submit rating) */
> 
>     /* menu/display items */
>     function getMenuItems();        /* return menu items related to 
> the plugin */    function getUserMenu();            /* return user 
> menu options */    function getAdminMenu();        /* return admin 
> menu options */    function getControlMenu();        /* return 
> control menu options */    function getCenterBlock();        /* 
> return centerblock */
> 
>     /* profile */
>     function getProfileBlock();        /* display plugin block 
> profile values */    function getEditProfileBlock();    /* return 
> form to edit block profile values */    function getProfileVar();    
>     /* display plugin variable profile values */    function 
> getEditProfileVar();    /* return form to edit variable profile 
> values */    function saveProfileOptions();  /* save plugin profile 
> options */
> 
>     /* export files (rdf feeds, ical files, etc) */
>     function getExportNames();        /* return export file names 
> the plugin uses */    function getExportContent();    /* return 
> export file content */    function getExportCurrent();    /* return 
> if exports are current */
> 
>     /* other */
>     function getHeaderCode();        /* return plugin JS or Meta 
> Data */    function getStats();            /* return plugin stats 
> information */ }
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From geeklog at langfamily.ca  Mon Oct 20 14:55:40 2003
From: geeklog at langfamily.ca (Blaine Lang)
Date: Mon, 20 Oct 2003 14:55:40 -0400
Subject: [geeklog-devel] Re: Geeklog 2 Module API
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org>
Message-ID: <002501c3973b$c1a05240$9a0a10ac@xpbl1>

Vinny,

I like the idea of having the plugin register itself with their capabilties.
As Tom notes, there may also be a way for a plugin to advertise new services
that may be available.

- Examples that I have close to release are:
1) Support for Smilies - Add/Edit Admin plus the replace functions but
standard Story Edit and Comment functions could also use this
2) Private Messenger - The one in chatterblock was a quick hack compared to
the new one I have now but other plugins may want to leverage this feature.
Example, I created a Project Mgmt Plugin for a client and they wanted the
options to received task notifications via the Private Messenger.

Another example is an image mgmt plugin that would provide a service to
allow users to add images to stories or other plugins that have content
functionality.

But as Tom notes, we will need someway to facilite or mediate over
conflicts.

Would there be a need to have or want a plugin function replace a core
function ?

I was not sure if you have used the most recent release when you reviewed
the PLG API functions. Dirk has added a number of new ones for syndication.

What about an internal Messaging protocal or service for plugins and Core
compoents to share or exchange information ?

GL 1.3.8 Added the new functions to extend the User and Account Profiles -
this was a great addition. If only now we had a way to auto extend or modify
the templates. GL2 will need to support a much improved template engine as
noted many times < but I digress off topic>
Is there a need to add an API to add/edit information to the cookie or
session variables ?

I can't think of any new API's that are needed. The 1.3.x framework has been
very good at fleshing this out and it's been nicely extended over the past
year.  I have not looked at XOOPS2 to see what they have done -  that may be
helpfull for ideas.

I'd like to see a way to import in a new plugin. Similar to a JAR file - a
zip file with the defined structure. The Plugin installer would un-archive
the contents, create the directories and run the installer script. I'd put
my hand up to work on that one. I think we need to also look at the Block
admin and have a similar feature.

Note: We may want to move some of the GL2 Discussion to the Geeklog.net
Forum. I can create a Developers Category and Forums that are restricted.

----- Original Message -----
From: "Vincent Furia" <vmf at abtech.org>
To: "Tony Bibbs" <tony at tonybibbs.com>
Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
Sent: Monday, October 20, 2003 2:29 AM
Subject: [geeklog-devel] Re: Geeklog 2 Module API


> OK, here is a first go at the module/plugin API to get things started.
> I thought that I would start by recommending that plugins "register"
> themselves during install with geeklog, including whether they use the
> different plugin APIs (moderation, comments, ratings, search, etc) so as
> to eliminate the "doesXXXX" type functions that may be needed otherwise
> (should also make things more efficient when calling functions for
> multiple plugins).
>
> In any case, please make lots of recommendations.  This doesn't really
> add much to what a plugin can do in GL 1.3.x, any new ideas would be
> very much appreciated.
>
> -Vinny
>
> <?php
> interface glPlugin {
>     /* installation functions */
>     function install();                /* install the plugin */
>     function uninstall();            /* uninstall the plugin */
>     function upgrade();                /* upgrade the plugin from a
> previous version */
>     function getVersion();            /* return plugin name and version
> (author(s)?, website?)*/
>
>     /* user modifications */
>     function onNewUser();            /* process new user */
>     function onDeleteUser();        /* process user deletion */
>
>     /* moderation */
>     function getSubmissionForm();    /* return the form for plugin
> submission */
>     function getModerationList();    /* return list of items for
> moderation */
>     function onApproveSubmission();    /* process a submission approval */
>     function onDeleteSubmission();    /* delete a submission */
>     function onEditSubmission();    /* return the form to edit a
> submission */
>     function getSubmissionCount();  /* return count of current
> submissions */
>
>     /* search functions */
>     function getSearchResults();    /* search items for keywords */
>     function getSearchTypes();        /* return plugin search options */
>
>     /* comment functions */
>     function onCommentAction();        /* plugin action on comment
> submit, delete, etc */
>     function getCommentParent();    /* for display of the parent above
> comments */
>
>     /* ratings functions */
>     function onRatingAction();        /* plugin action  on ratings
> actions (submit rating) */
>
>     /* menu/display items */
>     function getMenuItems();        /* return menu items related to the
> plugin */
>     function getUserMenu();            /* return user menu options */
>     function getAdminMenu();        /* return admin menu options */
>     function getControlMenu();        /* return control menu options */
>     function getCenterBlock();        /* return centerblock */
>
>     /* profile */
>     function getProfileBlock();        /* display plugin block profile
> values */
>     function getEditProfileBlock();    /* return form to edit block
> profile values */
>     function getProfileVar();        /* display plugin variable profile
> values */
>     function getEditProfileVar();    /* return form to edit variable
> profile values */
>     function saveProfileOptions();  /* save plugin profile options */
>
>     /* export files (rdf feeds, ical files, etc) */
>     function getExportNames();        /* return export file names the
> plugin uses */
>     function getExportContent();    /* return export file content */
>     function getExportCurrent();    /* return if exports are current */
>
>     /* other */
>     function getHeaderCode();        /* return plugin JS or Meta Data */
>     function getStats();            /* return plugin stats information */
> }
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From tony at tonybibbs.com  Mon Oct 20 17:46:31 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 20 Oct 2003 16:46:31 -0500
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <002501c3973b$c1a05240$9a0a10ac@xpbl1>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1>
Message-ID: <3F9457B7.8070306@tonybibbs.com>

Please note that GL2 has messenging capabilities built into the core 
parts of the code (as shown by the data model).  I couldn't agree more, 
modules may want to make use of this for sure.

As for modules interacting with one another, I think we need to 
implement observer/observable patterns.  In this scenario, a module can 
register events with Geeklog (e.g. on submission, on delete, on update, 
etc).  For each event, another module can register as an observer to the 
event of another.

This isn't anything but I"m suggesting methods like this:

// this, would be called during an installation of a module
function registerEvents($eventArray);

// this is called by the module when an event occurs
function raiseEvent($eventName);

// This is implemented by the listener of some othe module
function handleEvent($moduleName, $eventName);

This make sense?

--Tony

Blaine Lang wrote:
> Vinny,
> 
> I like the idea of having the plugin register itself with their capabilties.
> As Tom notes, there may also be a way for a plugin to advertise new services
> that may be available.
> 
> - Examples that I have close to release are:
> 1) Support for Smilies - Add/Edit Admin plus the replace functions but
> standard Story Edit and Comment functions could also use this
> 2) Private Messenger - The one in chatterblock was a quick hack compared to
> the new one I have now but other plugins may want to leverage this feature.
> Example, I created a Project Mgmt Plugin for a client and they wanted the
> options to received task notifications via the Private Messenger.
> 
> Another example is an image mgmt plugin that would provide a service to
> allow users to add images to stories or other plugins that have content
> functionality.
> 
> But as Tom notes, we will need someway to facilite or mediate over
> conflicts.
> 
> Would there be a need to have or want a plugin function replace a core
> function ?
> 
> I was not sure if you have used the most recent release when you reviewed
> the PLG API functions. Dirk has added a number of new ones for syndication.
> 
> What about an internal Messaging protocal or service for plugins and Core
> compoents to share or exchange information ?
> 
> GL 1.3.8 Added the new functions to extend the User and Account Profiles -
> this was a great addition. If only now we had a way to auto extend or modify
> the templates. GL2 will need to support a much improved template engine as
> noted many times < but I digress off topic>
> Is there a need to add an API to add/edit information to the cookie or
> session variables ?
> 
> I can't think of any new API's that are needed. The 1.3.x framework has been
> very good at fleshing this out and it's been nicely extended over the past
> year.  I have not looked at XOOPS2 to see what they have done -  that may be
> helpfull for ideas.
> 
> I'd like to see a way to import in a new plugin. Similar to a JAR file - a
> zip file with the defined structure. The Plugin installer would un-archive
> the contents, create the directories and run the installer script. I'd put
> my hand up to work on that one. I think we need to also look at the Block
> admin and have a similar feature.
> 
> Note: We may want to move some of the GL2 Discussion to the Geeklog.net
> Forum. I can create a Developers Category and Forums that are restricted.
> 
> ----- Original Message -----
> From: "Vincent Furia" <vmf at abtech.org>
> To: "Tony Bibbs" <tony at tonybibbs.com>
> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
> Sent: Monday, October 20, 2003 2:29 AM
> Subject: [geeklog-devel] Re: Geeklog 2 Module API
> 
> 
> 
>>OK, here is a first go at the module/plugin API to get things started.
>>I thought that I would start by recommending that plugins "register"
>>themselves during install with geeklog, including whether they use the
>>different plugin APIs (moderation, comments, ratings, search, etc) so as
>>to eliminate the "doesXXXX" type functions that may be needed otherwise
>>(should also make things more efficient when calling functions for
>>multiple plugins).
>>
>>In any case, please make lots of recommendations.  This doesn't really
>>add much to what a plugin can do in GL 1.3.x, any new ideas would be
>>very much appreciated.
>>
>>-Vinny
>>
>><?php
>>interface glPlugin {
>>    /* installation functions */
>>    function install();                /* install the plugin */
>>    function uninstall();            /* uninstall the plugin */
>>    function upgrade();                /* upgrade the plugin from a
>>previous version */
>>    function getVersion();            /* return plugin name and version
>>(author(s)?, website?)*/
>>
>>    /* user modifications */
>>    function onNewUser();            /* process new user */
>>    function onDeleteUser();        /* process user deletion */
>>
>>    /* moderation */
>>    function getSubmissionForm();    /* return the form for plugin
>>submission */
>>    function getModerationList();    /* return list of items for
>>moderation */
>>    function onApproveSubmission();    /* process a submission approval */
>>    function onDeleteSubmission();    /* delete a submission */
>>    function onEditSubmission();    /* return the form to edit a
>>submission */
>>    function getSubmissionCount();  /* return count of current
>>submissions */
>>
>>    /* search functions */
>>    function getSearchResults();    /* search items for keywords */
>>    function getSearchTypes();        /* return plugin search options */
>>
>>    /* comment functions */
>>    function onCommentAction();        /* plugin action on comment
>>submit, delete, etc */
>>    function getCommentParent();    /* for display of the parent above
>>comments */
>>
>>    /* ratings functions */
>>    function onRatingAction();        /* plugin action  on ratings
>>actions (submit rating) */
>>
>>    /* menu/display items */
>>    function getMenuItems();        /* return menu items related to the
>>plugin */
>>    function getUserMenu();            /* return user menu options */
>>    function getAdminMenu();        /* return admin menu options */
>>    function getControlMenu();        /* return control menu options */
>>    function getCenterBlock();        /* return centerblock */
>>
>>    /* profile */
>>    function getProfileBlock();        /* display plugin block profile
>>values */
>>    function getEditProfileBlock();    /* return form to edit block
>>profile values */
>>    function getProfileVar();        /* display plugin variable profile
>>values */
>>    function getEditProfileVar();    /* return form to edit variable
>>profile values */
>>    function saveProfileOptions();  /* save plugin profile options */
>>
>>    /* export files (rdf feeds, ical files, etc) */
>>    function getExportNames();        /* return export file names the
>>plugin uses */
>>    function getExportContent();    /* return export file content */
>>    function getExportCurrent();    /* return if exports are current */
>>
>>    /* other */
>>    function getHeaderCode();        /* return plugin JS or Meta Data */
>>    function getStats();            /* return plugin stats information */
>>}
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tony at tonybibbs.com  Mon Oct 20 19:25:59 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 20 Oct 2003 18:25:59 -0500
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <002501c3973b$c1a05240$9a0a10ac@xpbl1>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1>
Message-ID: <3F946F07.4090901@tonybibbs.com>

Related to this, I'd like to see modules be more flexible than simply 
supporting center blocks.  I have been reading a bit on the Java Portlet 
technology that basically allows you to break a single page up into 
portlets or little windows.  The size of the portlets are configurable 
and it is up to the module to return the content for the individual 
portlet.  I don't feel we should make our solution near as complicated 
as the Java version (otherwise where is our value-add) but I do think we 
should support more flexible layout types.

I will think about how this might effect the API.

--Tony

Blaine Lang wrote:
> Vinny,
> 
> I like the idea of having the plugin register itself with their capabilties.
> As Tom notes, there may also be a way for a plugin to advertise new services
> that may be available.
> 
> - Examples that I have close to release are:
> 1) Support for Smilies - Add/Edit Admin plus the replace functions but
> standard Story Edit and Comment functions could also use this
> 2) Private Messenger - The one in chatterblock was a quick hack compared to
> the new one I have now but other plugins may want to leverage this feature.
> Example, I created a Project Mgmt Plugin for a client and they wanted the
> options to received task notifications via the Private Messenger.
> 
> Another example is an image mgmt plugin that would provide a service to
> allow users to add images to stories or other plugins that have content
> functionality.
> 
> But as Tom notes, we will need someway to facilite or mediate over
> conflicts.
> 
> Would there be a need to have or want a plugin function replace a core
> function ?
> 
> I was not sure if you have used the most recent release when you reviewed
> the PLG API functions. Dirk has added a number of new ones for syndication.
> 
> What about an internal Messaging protocal or service for plugins and Core
> compoents to share or exchange information ?
> 
> GL 1.3.8 Added the new functions to extend the User and Account Profiles -
> this was a great addition. If only now we had a way to auto extend or modify
> the templates. GL2 will need to support a much improved template engine as
> noted many times < but I digress off topic>
> Is there a need to add an API to add/edit information to the cookie or
> session variables ?
> 
> I can't think of any new API's that are needed. The 1.3.x framework has been
> very good at fleshing this out and it's been nicely extended over the past
> year.  I have not looked at XOOPS2 to see what they have done -  that may be
> helpfull for ideas.
> 
> I'd like to see a way to import in a new plugin. Similar to a JAR file - a
> zip file with the defined structure. The Plugin installer would un-archive
> the contents, create the directories and run the installer script. I'd put
> my hand up to work on that one. I think we need to also look at the Block
> admin and have a similar feature.
> 
> Note: We may want to move some of the GL2 Discussion to the Geeklog.net
> Forum. I can create a Developers Category and Forums that are restricted.
> 
> ----- Original Message -----
> From: "Vincent Furia" <vmf at abtech.org>
> To: "Tony Bibbs" <tony at tonybibbs.com>
> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
> Sent: Monday, October 20, 2003 2:29 AM
> Subject: [geeklog-devel] Re: Geeklog 2 Module API
> 
> 
> 
>>OK, here is a first go at the module/plugin API to get things started.
>>I thought that I would start by recommending that plugins "register"
>>themselves during install with geeklog, including whether they use the
>>different plugin APIs (moderation, comments, ratings, search, etc) so as
>>to eliminate the "doesXXXX" type functions that may be needed otherwise
>>(should also make things more efficient when calling functions for
>>multiple plugins).
>>
>>In any case, please make lots of recommendations.  This doesn't really
>>add much to what a plugin can do in GL 1.3.x, any new ideas would be
>>very much appreciated.
>>
>>-Vinny
>>
>><?php
>>interface glPlugin {
>>    /* installation functions */
>>    function install();                /* install the plugin */
>>    function uninstall();            /* uninstall the plugin */
>>    function upgrade();                /* upgrade the plugin from a
>>previous version */
>>    function getVersion();            /* return plugin name and version
>>(author(s)?, website?)*/
>>
>>    /* user modifications */
>>    function onNewUser();            /* process new user */
>>    function onDeleteUser();        /* process user deletion */
>>
>>    /* moderation */
>>    function getSubmissionForm();    /* return the form for plugin
>>submission */
>>    function getModerationList();    /* return list of items for
>>moderation */
>>    function onApproveSubmission();    /* process a submission approval */
>>    function onDeleteSubmission();    /* delete a submission */
>>    function onEditSubmission();    /* return the form to edit a
>>submission */
>>    function getSubmissionCount();  /* return count of current
>>submissions */
>>
>>    /* search functions */
>>    function getSearchResults();    /* search items for keywords */
>>    function getSearchTypes();        /* return plugin search options */
>>
>>    /* comment functions */
>>    function onCommentAction();        /* plugin action on comment
>>submit, delete, etc */
>>    function getCommentParent();    /* for display of the parent above
>>comments */
>>
>>    /* ratings functions */
>>    function onRatingAction();        /* plugin action  on ratings
>>actions (submit rating) */
>>
>>    /* menu/display items */
>>    function getMenuItems();        /* return menu items related to the
>>plugin */
>>    function getUserMenu();            /* return user menu options */
>>    function getAdminMenu();        /* return admin menu options */
>>    function getControlMenu();        /* return control menu options */
>>    function getCenterBlock();        /* return centerblock */
>>
>>    /* profile */
>>    function getProfileBlock();        /* display plugin block profile
>>values */
>>    function getEditProfileBlock();    /* return form to edit block
>>profile values */
>>    function getProfileVar();        /* display plugin variable profile
>>values */
>>    function getEditProfileVar();    /* return form to edit variable
>>profile values */
>>    function saveProfileOptions();  /* save plugin profile options */
>>
>>    /* export files (rdf feeds, ical files, etc) */
>>    function getExportNames();        /* return export file names the
>>plugin uses */
>>    function getExportContent();    /* return export file content */
>>    function getExportCurrent();    /* return if exports are current */
>>
>>    /* other */
>>    function getHeaderCode();        /* return plugin JS or Meta Data */
>>    function getStats();            /* return plugin stats information */
>>}
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel


-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From tony at tonybibbs.com  Mon Oct 20 19:26:24 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 20 Oct 2003 18:26:24 -0500
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <002501c3973b$c1a05240$9a0a10ac@xpbl1>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1>
Message-ID: <3F946F20.8030202@tonybibbs.com>

Related to this, I'd like to see modules be more flexible than simply 
supporting center blocks.  I have been reading a bit on the Java Portlet 
technology that basically allows you to break a single page up into 
portlets or little windows.  The size of the portlets are configurable 
and it is up to the module to return the content for the individual 
portlet.  I don't feel we should make our solution near as complicated 
as the Java version (otherwise where is our value-add) but I do think we 
should support more flexible layout types.

I will think about how this might effect the API.

--Tony

Blaine Lang wrote:
> Vinny,
> 
> I like the idea of having the plugin register itself with their capabilties.
> As Tom notes, there may also be a way for a plugin to advertise new services
> that may be available.
> 
> - Examples that I have close to release are:
> 1) Support for Smilies - Add/Edit Admin plus the replace functions but
> standard Story Edit and Comment functions could also use this
> 2) Private Messenger - The one in chatterblock was a quick hack compared to
> the new one I have now but other plugins may want to leverage this feature.
> Example, I created a Project Mgmt Plugin for a client and they wanted the
> options to received task notifications via the Private Messenger.
> 
> Another example is an image mgmt plugin that would provide a service to
> allow users to add images to stories or other plugins that have content
> functionality.
> 
> But as Tom notes, we will need someway to facilite or mediate over
> conflicts.
> 
> Would there be a need to have or want a plugin function replace a core
> function ?
> 
> I was not sure if you have used the most recent release when you reviewed
> the PLG API functions. Dirk has added a number of new ones for syndication.
> 
> What about an internal Messaging protocal or service for plugins and Core
> compoents to share or exchange information ?
> 
> GL 1.3.8 Added the new functions to extend the User and Account Profiles -
> this was a great addition. If only now we had a way to auto extend or modify
> the templates. GL2 will need to support a much improved template engine as
> noted many times < but I digress off topic>
> Is there a need to add an API to add/edit information to the cookie or
> session variables ?
> 
> I can't think of any new API's that are needed. The 1.3.x framework has been
> very good at fleshing this out and it's been nicely extended over the past
> year.  I have not looked at XOOPS2 to see what they have done -  that may be
> helpfull for ideas.
> 
> I'd like to see a way to import in a new plugin. Similar to a JAR file - a
> zip file with the defined structure. The Plugin installer would un-archive
> the contents, create the directories and run the installer script. I'd put
> my hand up to work on that one. I think we need to also look at the Block
> admin and have a similar feature.
> 
> Note: We may want to move some of the GL2 Discussion to the Geeklog.net
> Forum. I can create a Developers Category and Forums that are restricted.
> 
> ----- Original Message -----
> From: "Vincent Furia" <vmf at abtech.org>
> To: "Tony Bibbs" <tony at tonybibbs.com>
> Cc: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
> Sent: Monday, October 20, 2003 2:29 AM
> Subject: [geeklog-devel] Re: Geeklog 2 Module API
> 
> 
> 
>>OK, here is a first go at the module/plugin API to get things started.
>>I thought that I would start by recommending that plugins "register"
>>themselves during install with geeklog, including whether they use the
>>different plugin APIs (moderation, comments, ratings, search, etc) so as
>>to eliminate the "doesXXXX" type functions that may be needed otherwise
>>(should also make things more efficient when calling functions for
>>multiple plugins).
>>
>>In any case, please make lots of recommendations.  This doesn't really
>>add much to what a plugin can do in GL 1.3.x, any new ideas would be
>>very much appreciated.
>>
>>-Vinny
>>
>><?php
>>interface glPlugin {
>>    /* installation functions */
>>    function install();                /* install the plugin */
>>    function uninstall();            /* uninstall the plugin */
>>    function upgrade();                /* upgrade the plugin from a
>>previous version */
>>    function getVersion();            /* return plugin name and version
>>(author(s)?, website?)*/
>>
>>    /* user modifications */
>>    function onNewUser();            /* process new user */
>>    function onDeleteUser();        /* process user deletion */
>>
>>    /* moderation */
>>    function getSubmissionForm();    /* return the form for plugin
>>submission */
>>    function getModerationList();    /* return list of items for
>>moderation */
>>    function onApproveSubmission();    /* process a submission approval */
>>    function onDeleteSubmission();    /* delete a submission */
>>    function onEditSubmission();    /* return the form to edit a
>>submission */
>>    function getSubmissionCount();  /* return count of current
>>submissions */
>>
>>    /* search functions */
>>    function getSearchResults();    /* search items for keywords */
>>    function getSearchTypes();        /* return plugin search options */
>>
>>    /* comment functions */
>>    function onCommentAction();        /* plugin action on comment
>>submit, delete, etc */
>>    function getCommentParent();    /* for display of the parent above
>>comments */
>>
>>    /* ratings functions */
>>    function onRatingAction();        /* plugin action  on ratings
>>actions (submit rating) */
>>
>>    /* menu/display items */
>>    function getMenuItems();        /* return menu items related to the
>>plugin */
>>    function getUserMenu();            /* return user menu options */
>>    function getAdminMenu();        /* return admin menu options */
>>    function getControlMenu();        /* return control menu options */
>>    function getCenterBlock();        /* return centerblock */
>>
>>    /* profile */
>>    function getProfileBlock();        /* display plugin block profile
>>values */
>>    function getEditProfileBlock();    /* return form to edit block
>>profile values */
>>    function getProfileVar();        /* display plugin variable profile
>>values */
>>    function getEditProfileVar();    /* return form to edit variable
>>profile values */
>>    function saveProfileOptions();  /* save plugin profile options */
>>
>>    /* export files (rdf feeds, ical files, etc) */
>>    function getExportNames();        /* return export file names the
>>plugin uses */
>>    function getExportContent();    /* return export file content */
>>    function getExportCurrent();    /* return if exports are current */
>>
>>    /* other */
>>    function getHeaderCode();        /* return plugin JS or Meta Data */
>>    function getStats();            /* return plugin stats information */
>>}
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel


-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+



From vmf at abtech.org  Tue Oct 21 16:18:37 2003
From: vmf at abtech.org (Vincent Furia)
Date: Tue, 21 Oct 2003 13:18:37 -0700
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <3F946F20.8030202@tonybibbs.com>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1> <3F946F20.8030202@tonybibbs.com>
Message-ID: <3F95949D.5070403@abtech.org>

OK, I've included some of the ideas mentioned so far on the thread, 
including those that Warren mentioned on geeklog-devtalk.  The slightly 
modified module API is included below.  I forgot to mention this in the 
previous email, but I had wanted to say that I was only working on the 
call-back functions.  So functions like registering events and APIs 
weren't included because those should be called by the from within the 
plugin code, rather than by the core geeklog code.  Outlining all the 
functions available to the modules would be huge undertaking, but maybe 
something we should work on at the same time as the interace.

Here are some of the functions that would be called by the modules.  
Perhaps these should all be contained within a non-instantiated class?

function registerAPI();
function unregisterAPI();
function registerEvents();
function rasiseEvent();
function getSmiles();
function sendMessage();
function sendEmail();

On top of these there should probably be classes and functions available 
to handle common tasks like file (and image) uploads.

Tony, I'm not an XHTML/CSS deity, but I think a lot could be 
accomplished by modules generating html div blocks that then could be 
modified by css classes.  That combined with some creative function 
calls could get theme developers enough flexibility...  But again, my 
knowledge of css/xhtml isn't thorough enough to know if that would be 
sufficient.

Also that brings us to one of Warren's points about injecting code into 
template files. Should this be handled by functions or by editing the 
template manually...?  I guess this depends on the template system we're 
going to use (looks like FLEXY currently I believe) and what sort of 
magic we can do.  I'm hesitant to create fifty (or however many) 
functions so that the plugins can place code anywhere.  I think we'll 
wind up adding a new function every time a plugin or theme developer 
decides they need access to a new location to achieve a certain look... 
I think this is something we should sort out soon.

Should we move this discussion on the forums?  It really doesn't matter 
to me. We could also move the discussion onto project.geeklog.net which 
might give us a bit more flexibility than using the geeklog.net forums...

Anyway, I just want to emphasize the difference between callback 
functions and functions that will called by the plugin.  It will make 
things easier if everyone keeps the distinction in mind as we work on 
the two simultaneously.

One last question I suppose.  For GL2 are we calling them "plugins", 
"modules" or will we just continue using the two terms interchangably 
until we confuse everyone?  ;)

-Vinny

<?php
interface glPlugin {
    /* installation functions */
    function install();                /* install the plugin */
    function uninstall();            /* uninstall the plugin */
    function upgrade();                /* upgrade the plugin from a 
previous version */
    function getVersion();            /* return plugin name and version 
(author(s)?, website?)*/

    /* user modifications */
    function onNewUser();            /* process new user */
    function onDeleteUser();        /* process user deletion */
    function onLogin();                /* process user login */
    function onLogout();            /* process user logout */

    /* moderation */
    function getSubmissionForm();    /* return the form for plugin 
submission */
    function getModerationList();    /* return list of items for 
moderation */
    function onApproveSubmission();    /* process a submission approval */
    function onDeleteSubmission();    /* delete a submission */
    function onEditSubmission();    /* return the form to edit a 
submission */
    function getSubmissionCount();  /* return count of current 
submissions */

    /* search functions */
    function getSearchResults();    /* search items for keywords */
    function getSearchTypes();        /* return plugin search options */

    /* comment functions */
    function onCommentAction();        /* plugin action on comment 
submit, delete, etc */
    function getCommentParent();    /* for display of the parent above 
comments */

    /* ratings functions */
    function onRatingAction();        /* plugin action  on ratings 
actions (submit rating) */

    /* menu/display items */
    function getMenuItems();        /* return menu items related to the 
plugin */
    function getUserMenu();            /* return user menu options */
    function getAdminMenu();        /* return admin menu options */
    function getControlMenu();        /* return control menu options */
    function getCenterBlock();        /* return centerblock */

    /* profile */
    function getProfileBlock();        /* display plugin block profile 
values */
    function getEditProfileBlock();    /* return form to edit block 
profile values */
    function getProfileVar();        /* display plugin variable profile 
values */
    function getEditProfileVar();    /* return form to edit variable 
profile values */
    function saveProfileOptions();  /* save plugin profile options */

    /* export files (rdf feeds, ical files, etc) */
    function getExportNames();        /* return export file names the 
plugin uses */
    function getExportContent();    /* return export file content */
    function getExportCurrent();    /* return if exports are current */

    /* other */
    function getHeaderCode();        /* return plugin JS or Meta Data */
    function getStats();            /* return plugin stats information */
    function onEvent();                /* handle a registered event */
}



From tony at tonybibbs.com  Tue Oct 21 18:10:08 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 21 Oct 2003 17:10:08 -0500
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <3F95949D.5070403@abtech.org>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1> <3F946F20.8030202@tonybibbs.com> <3F95949D.5070403@abtech.org>
Message-ID: <3F95AEC0.5060003@tonybibbs.com>

The layout portion of this is not going to be the easiest I can already 
see that.  We need to get Knuckles in on this conversation (is the guy 
alive?).  As for my ideas around layout here is what I am thinking. 
First, I think we should consider a method like:

function getBlock($blockName, $width, $height)
{
}

This would allow you to, in a page call for individual blocks directly. 
  Passing the width/height allows some flexibility on the provider of 
the block's content (probably a module) to pick and choose how to 
display itself based on the dimisions (if it wanted to).

Other input on how to add flexibility to the layout yet keep this 
relatively simple would be appreciated.

On another note, should PM's or emails be part of the API or done by 
calling the native GL core code?  Not sure if I have an opinion yet.

Thanks Vinny, it's coming along nicely.

--Tony

Vincent Furia wrote:
> OK, I've included some of the ideas mentioned so far on the thread, 
> including those that Warren mentioned on geeklog-devtalk.  The slightly 
> modified module API is included below.  I forgot to mention this in the 
> previous email, but I had wanted to say that I was only working on the 
> call-back functions.  So functions like registering events and APIs 
> weren't included because those should be called by the from within the 
> plugin code, rather than by the core geeklog code.  Outlining all the 
> functions available to the modules would be huge undertaking, but maybe 
> something we should work on at the same time as the interace.
> 
> Here are some of the functions that would be called by the modules.  
> Perhaps these should all be contained within a non-instantiated class?
> 
> function registerAPI();
> function unregisterAPI();
> function registerEvents();
> function rasiseEvent();
> function getSmiles();
> function sendMessage();
> function sendEmail();
> 
> On top of these there should probably be classes and functions available 
> to handle common tasks like file (and image) uploads.
> 
> Tony, I'm not an XHTML/CSS deity, but I think a lot could be 
> accomplished by modules generating html div blocks that then could be 
> modified by css classes.  That combined with some creative function 
> calls could get theme developers enough flexibility...  But again, my 
> knowledge of css/xhtml isn't thorough enough to know if that would be 
> sufficient.
> 
> Also that brings us to one of Warren's points about injecting code into 
> template files. Should this be handled by functions or by editing the 
> template manually...?  I guess this depends on the template system we're 
> going to use (looks like FLEXY currently I believe) and what sort of 
> magic we can do.  I'm hesitant to create fifty (or however many) 
> functions so that the plugins can place code anywhere.  I think we'll 
> wind up adding a new function every time a plugin or theme developer 
> decides they need access to a new location to achieve a certain look... 
> I think this is something we should sort out soon.
> 
> Should we move this discussion on the forums?  It really doesn't matter 
> to me. We could also move the discussion onto project.geeklog.net which 
> might give us a bit more flexibility than using the geeklog.net forums...
> 
> Anyway, I just want to emphasize the difference between callback 
> functions and functions that will called by the plugin.  It will make 
> things easier if everyone keeps the distinction in mind as we work on 
> the two simultaneously.
> 
> One last question I suppose.  For GL2 are we calling them "plugins", 
> "modules" or will we just continue using the two terms interchangably 
> until we confuse everyone?  ;)
> 
> -Vinny
> 
> <?php
> interface glPlugin {
>    /* installation functions */
>    function install();                /* install the plugin */
>    function uninstall();            /* uninstall the plugin */
>    function upgrade();                /* upgrade the plugin from a 
> previous version */
>    function getVersion();            /* return plugin name and version 
> (author(s)?, website?)*/
> 
>    /* user modifications */
>    function onNewUser();            /* process new user */
>    function onDeleteUser();        /* process user deletion */
>    function onLogin();                /* process user login */
>    function onLogout();            /* process user logout */
> 
>    /* moderation */
>    function getSubmissionForm();    /* return the form for plugin 
> submission */
>    function getModerationList();    /* return list of items for 
> moderation */
>    function onApproveSubmission();    /* process a submission approval */
>    function onDeleteSubmission();    /* delete a submission */
>    function onEditSubmission();    /* return the form to edit a 
> submission */
>    function getSubmissionCount();  /* return count of current 
> submissions */
> 
>    /* search functions */
>    function getSearchResults();    /* search items for keywords */
>    function getSearchTypes();        /* return plugin search options */
> 
>    /* comment functions */
>    function onCommentAction();        /* plugin action on comment 
> submit, delete, etc */
>    function getCommentParent();    /* for display of the parent above 
> comments */
> 
>    /* ratings functions */
>    function onRatingAction();        /* plugin action  on ratings 
> actions (submit rating) */
> 
>    /* menu/display items */
>    function getMenuItems();        /* return menu items related to the 
> plugin */
>    function getUserMenu();            /* return user menu options */
>    function getAdminMenu();        /* return admin menu options */
>    function getControlMenu();        /* return control menu options */
>    function getCenterBlock();        /* return centerblock */
> 
>    /* profile */
>    function getProfileBlock();        /* display plugin block profile 
> values */
>    function getEditProfileBlock();    /* return form to edit block 
> profile values */
>    function getProfileVar();        /* display plugin variable profile 
> values */
>    function getEditProfileVar();    /* return form to edit variable 
> profile values */
>    function saveProfileOptions();  /* save plugin profile options */
> 
>    /* export files (rdf feeds, ical files, etc) */
>    function getExportNames();        /* return export file names the 
> plugin uses */
>    function getExportContent();    /* return export file content */
>    function getExportCurrent();    /* return if exports are current */
> 
>    /* other */
>    function getHeaderCode();        /* return plugin JS or Meta Data */
>    function getStats();            /* return plugin stats information */
>    function onEvent();                /* handle a registered event */
> }
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From geeklog at langfamily.ca  Tue Oct 21 19:19:39 2003
From: geeklog at langfamily.ca (Blaine Lang)
Date: Tue, 21 Oct 2003 19:19:39 -0400
Subject: [geeklog-devel] Re: Geeklog 2 Module API
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1> <3F946F20.8030202@tonybibbs.com> <3F95949D.5070403@abtech.org> <3F95AEC0.5060003@tonybibbs.com>
Message-ID: <004a01c39829$ccffe7b0$9a0a10ac@xpbl1>

Comments:

1) Block formatting:
1.1: I like the idea of being able to restrict the block formatting but not
sure how that would be implemented
Are these user preferences - I want left blocks to be 20% , center to be 40%
and right to be 40% ?
User can decide to have a 2 col view vs 3 col view

1.2: I've used several commercial portals that allow the user to control the
layout of modules or blocks on the page
pages the user can control the layout and others are defined by the admin -
so user control.
Usefull if the admin so the admin can pre-define fixed layout and then let
users add content and blocks/plugins from a library and define the layout
they want.

1.3: I like the feature we have today where I can specify the template to be
used by a block.

1.4: The template functions.php is a great concept that we have today - need
to keep this.

2) Plugin API's

2.1: Not sure we need if getSimiles() was just an example or a suggested
API.
I think we need a more generic API call that a plugin can then provide any
post-processing (as example: smilie substitution)
How about an API that was called to post-process all stories upon post,
display or preview. This may then call the registered and enabled smilie
plugin or BB-Code plugin or ImageMgmt Plugin or SpellChecker plugin.

We may need additional calls to handle the return codes from these plugin
functions should there be exceptions

2.2: Publish and Subscribe API's
GL2 Needs to have a core subscription montoring capability. Allow a user to
identify what they want to subscribe to for alerts
Plugin would then call an API to register they can provide a subscription
service. Need to think about this a bit more but the I've created a few
plugins now that duplicate this functionality.
  - Forum: Users subscribe to topics and forums they want to watch
  - Project Mgmt Plugin: Users subscribe to tasks or projects they want to
be notified of any changes
  - FileMgmt Plugin: Uses subscribe to categories or files they want to be
notified of changes

Users may want to subsribe to GL Topics or Links or Authors.

2.3: Ability for the portal to track whats changed - may be a support
function of the subscribe feature
It would be great if a member could see all that has changed since his last
visit.
Plugins would call an API to register a change  - Is this a variation of
OnEvent()

2.4) Users should be able to define how they want to be notified of
subscribed alerts or subscriptions
This may be: email, PM plugin, Instant Messenger etc ...

I'd recommend the PM function not be a Core Service but that it be a plugin
so it could be replaced. There is a need for a Core messaging service and we
can provide a PM plugin as part of the general release. But it should not be
dependant on that module and could be replaced.

What are they called - choices:
Gadgets
Modules
Blocks
Plugins
Portlets
eclips
components
xApps
microapps

I still prefer: Plugins (for integrated mini-apps) and blocks.




From tony at tonybibbs.com  Wed Oct 22 10:25:08 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 22 Oct 2003 09:25:08 -0500
Subject: [geeklog-devel] Re: Geeklog 2 Module API
In-Reply-To: <004a01c39829$ccffe7b0$9a0a10ac@xpbl1>
References: <3F905E85.6030505@tonybibbs.com> <3F9380D5.8010500@abtech.org> <002501c3973b$c1a05240$9a0a10ac@xpbl1> <3F946F20.8030202@tonybibbs.com> <3F95949D.5070403@abtech.org> <3F95AEC0.5060003@tonybibbs.com> <004a01c39829$ccffe7b0$9a0a10ac@xpbl1>
Message-ID: <3F969344.1080306@tonybibbs.com>


Blaine Lang wrote:
> Comments:
> 
> 1) Block formatting:
> 1.1: I like the idea of being able to restrict the block formatting but not
> sure how that would be implemented
> Are these user preferences - I want left blocks to be 20% , center to be 40%
> and right to be 40% ?
> User can decide to have a 2 col view vs 3 col view
> 
> 1.2: I've used several commercial portals that allow the user to control the
> layout of modules or blocks on the page
> pages the user can control the layout and others are defined by the admin -
> so user control.
> Usefull if the admin so the admin can pre-define fixed layout and then let
> users add content and blocks/plugins from a library and define the layout
> they want.

Allowing users to dynamically change the layout of a given theme is a 
difficult task.  I would prefer that the theme offer a finite set of 
choices instead.  This make the theme impelementation a little tougher 
but doesn't make the entire layout management a real nightmare.  Just my 
two cents.

> 
> 1.3: I like the feature we have today where I can specify the template to be
> used by a block.
> 
> 1.4: The template functions.php is a great concept that we have today - need
> to keep this.

Agreed to both of the above.

> 
> 2) Plugin API's
> 
> 2.1: Not sure we need if getSimiles() was just an example or a suggested
> API.
> I think we need a more generic API call that a plugin can then provide any
> post-processing (as example: smilie substitution)
> How about an API that was called to post-process all stories upon post,
> display or preview. This may then call the registered and enabled smilie
> plugin or BB-Code plugin or ImageMgmt Plugin or SpellChecker plugin.

If you look at my suggestions for event-based processing, I think you 
can get all this from that.

> 
> We may need additional calls to handle the return codes from these plugin
> functions should there be exceptions

PHP5 has exception handling built in (i.e. try and catch like Java). 
We'll plan on using that.

> 
> 2.2: Publish and Subscribe API's
> GL2 Needs to have a core subscription montoring capability. Allow a user to
> identify what they want to subscribe to for alerts
> Plugin would then call an API to register they can provide a subscription
> service. Need to think about this a bit more but the I've created a few
> plugins now that duplicate this functionality.
>   - Forum: Users subscribe to topics and forums they want to watch
>   - Project Mgmt Plugin: Users subscribe to tasks or projects they want to
> be notified of any changes
>   - FileMgmt Plugin: Uses subscribe to categories or files they want to be
> notified of changes
> 
> Users may want to subsribe to GL Topics or Links or Authors.

Anything deemed an 'item' in GL2 will give the user the ability to 
listen or watch it.  Take a look at the GL2 data model we have so far 
and look at the item and watches table.  So, in short, I think we have 
this covered.

> 
> 2.3: Ability for the portal to track whats changed - may be a support
> function of the subscribe feature
> It would be great if a member could see all that has changed since his last
> visit.
> Plugins would call an API to register a change  - Is this a variation of
> OnEvent()

Could be.  My only issue here is to be able to know what's changed since 
the last visit we would need to track when the last visit was.  Because 
we are using a custom PHP session handler I think we can work into the 
garbage collection routines that when we delete an expired session that 
we tag the last visit date/time on teh user account then.  This is good 
because it would prevent us from having to update the database on each 
page request.  As far as modules notifying one another or even GL2's 
core system we can probably plan on using the event-based stuff.

> 
> 2.4) Users should be able to define how they want to be notified of
> subscribed alerts or subscriptions
> This may be: email, PM plugin, Instant Messenger etc ...

Great idea.

> 
> I'd recommend the PM function not be a Core Service but that it be a plugin
> so it could be replaced. There is a need for a Core messaging service and we
> can provide a PM plugin as part of the general release. But it should not be
> dependant on that module and could be replaced.

When I say it is a core service I mean it will be a core module that has 
to be in place with all GL2 installations.  That way you can upgrade it 
like a module but all modules are gauranteed that the module will be 
there.  It will be important that the interface for using the messaging 
system be well thought out because if we change it then the way modules 
use it will probably change too.

> 
> What are they called - choices:
> Gadgets
> Modules
> Blocks
> Plugins
> Portlets
> eclips
> components
> xApps
> microapps
> 
> I still prefer: Plugins (for integrated mini-apps) and blocks.
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tony at tonybibbs.com  Thu Oct 23 18:49:22 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 23 Oct 2003 17:49:22 -0500
Subject: [geeklog-devel] GL2 Update
Message-ID: <3F985AF2.8040905@tonybibbs.com>

Well, as most of you know I got a bit side tracked on GL2 while I 
started in writing the Auth_Enterprise library which will be responsible 
for doing authentication and authorization.  This will be a PEAR module 
(it's already been accepted) and I have reworked much of what I have to 
have the PEAR file structure and have modified the old code to now use 
XMLRPC.  Right now I have authentication working..it's the only method 
that can go from the client to the server and back.  This was a big step 
as much of my time was learning how the PEAR::XML_RPC libararies worked. 
  I will now go through and update the rest of the methods on the server 
to use XMLPRC and add fault handling.  The current code is now in CVS.

XMLRPC is the default handler for Auth_Enterprise but I will need to 
work in support for those instances where the client application 
(Geeklog) and the service on on the same box.  The localhost 
implementation will faster (because it eliminates the network) and 
thinner (it will call the service methods directly) and will probably be 
the standard method for most GL installations.

When that is done, version 1 of Auth_Enterprise will be done in my 
opinoin.  From there we will need to hook this up to GL2's codebase and 
Vinny's new system for security.

As many of you saw Vinny is busy working on the Module API in the 
meantime. I saw a lot of great feedback going on around this.  I would 
encourage you all to keep the input coming as that is one of the more 
critical aspects of GL2.

That's all for now, questions are welcome.

--Tony

+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From vmf at abtech.org  Mon Oct 27 13:41:19 2003
From: vmf at abtech.org (Vincent Furia)
Date: Mon, 27 Oct 2003 10:41:19 -0800
Subject: [geeklog-devel] Re: [geeklog-security] profiles.php
In-Reply-To: <6.0.0.22.0.20031016134106.01d5cd98@localhost>
References: <3F8EBA08.4080601@abtech.org> <6.0.0.22.0.20031016134106.01d5cd98@localhost>
Message-ID: <3F9D66CF.7020909@abtech.org>

I've attached a fix to profiles.php that corrects all the errors posted 
below.  I've patched my changes on top of cvs latest, so it should be 
able to be place right on top of the current profiles.php.  The only 
other thing that needs to be taken care of is error messages for 
incorrect permissions to send the email and the speed limit check.  For 
the timing being I've just placed in COM_refresh, as the error message 
will require changes to the language files...  The changes made were 
primarily to the contactemail and mailstory functions.

Enjoy,
Vinny

Dwight Trumbower wrote:

> So when are you going to announce this to Full disclosure? :) :)
>
>
> At 10:32 AM 10/16/2003, you wrote:
>
>> Versions: Alll 1.3.x versions (at least back to 1.3.5)
>>
>> Allows the attacker (anonymous or registered) to send emails to users 
>> regardless of their allow email account setting and regardless of 
>> site settings allowing anonymous users to use the email utility (i.e. 
>> $_CONF['loginrequired'] or $_CONF['emailuserloginrequired']).
>>
>> Also there is no speedlimit for sending emails in this way.  While 
>> fixing these problems, I'd also recommend all emails going to the 
>> site admin (uid = 2) be allowed for website contact purposes.
>>
>> This could, theorectically be used to spam all of a site's users.
>>
>> The problem is in profiles.php, the contactemail function is called 
>> without checking (either within the function or before the function 
>> is called) the $_CONF variables or the user being emailed's preferences.
>> These are only checked when creating the email form.  The exploit 
>> simply by-passes using the form by doing a HTTP POST to profiles.php.
>>
>> This seems to me to be a pretty minor bug as no personal information 
>> is at risk and there is not opportunity to promote an attacker's 
>> rights.  I do think a fix should be released with 1.3.9.  I'll code 
>> up a fix if you'd like, it should be very straight forward.
>>
>> -Vinny
>>
>> Example Exploit:
>> > telnet site_url 80
>>
>> POST /profiles.php HTTP/1.1
>> Host: site_url
>> Content-Type: application/x-www-form-urlencoded
>> Content-Length: 98
>>
>> author=Hacker&authoremail=hack%40hack.org&subject=Testing&message=Testing+2+4+6&what=contact&uid=2 
>>
>>
>>
>>
>> _______________________________________________
>> geeklog-security mailing list
>> geeklog-security at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-security
>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20031027/19191124/attachment.html>

From tony at tonybibbs.com  Tue Oct 28 09:06:08 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 28 Oct 2003 08:06:08 -0600
Subject: [geeklog-devel] Section 508
Message-ID: <3F9E77D0.1040400@tonybibbs.com>

Anybody know how hard it would be to make a Section 508 compatible theme 
in Geeklog?  For details go here:

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web

I have a project that would make a decent fit for a customer, Iowa Dept. 
of Inspections and Appeals (http://www.dia-hfd.state.ia.us).  At work we 
have to redesign the entire site which is based on some ASP code and 
Access databases.  I think 70% of their content needs could be met with 
Geeklog and the rest would either need to be plugins or, possibly, Java 
applications.

Looking at the requirements for 508 compatibility is looks fairly 
doable...I just want to make sure I'm not missing anything.

Simon, I cc'd you in explicitly as I haven't seen you lately ;-)

--Tony

+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tony at tonybibbs.com  Tue Oct 28 10:09:17 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 28 Oct 2003 09:09:17 -0600
Subject: [geeklog-devel] Anti Spam Features
Message-ID: <3F9E869D.5070508@tonybibbs.com>

As noted in the forums of Geeklog.net it appears a growing trend is the 
spamming of blogs.  With Geeklog a big player in this arena I think we 
would be wise to start thinking up ways to implement anti-spam measures.

I think the start would be to be able to mark comments as spam.  When a 
comment is identified as spam I think the IP should be logged.  In the 
config.php file I think we could then set a spam threshold at say 5. 
What that means is if a an IP is tied to spamming the Geeklog site five 
times then we would ban that IP.  I know using IP's isn't the greatest 
but my hunch is 99% of this sort of spam would come from static IP's and 
not proxy IP's.  However, we should still allow admins to turn this 
feature on or off.

One other bit of useful logic would be to check if the source IP of spam 
has been tied to comments which weren't identified as spam.  If we did 
that then in our logic we could basically check a) has the IP hit the 
threshold, if so has it been used in non-spam comments.  If it *has* 
been used in non-spam comments then we could assume it is from a proxied 
IP and not ban the IP.

I also think later versions of this could use MySQL's full text 
searching capabilities.

To start, if we were to add the IP to the comment table I think we could 
write a plugin to do all this.  OF course this assumes that a plugin API 
is called when a comment is submitted which may or may not be the case ( 
I can't remember).

I'm sure you guys may have other ideas too.

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tomw at pigstye.net  Tue Oct 28 11:03:16 2003
From: tomw at pigstye.net (Tom Willett)
Date: Tue, 28 Oct 2003 16:03:16 +0000
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <3F9E869D.5070508@tonybibbs.com>
References: <3F9E869D.5070508@tonybibbs.com>
Message-ID: <20031028155706.M5829@pigstye.net>

Add the ip to the comments in geeklog and my ban plugin could easily handle 
the rest.  

All I would have to do is add the logic to check for the repeated spam 
comments.


--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: Geeklog Development <geeklog-devel at lists.geeklog.net>
Sent: Tue, 28 Oct 2003 09:09:17 -0600
Subject: [geeklog-devel] Anti Spam Features

> As noted in the forums of Geeklog.net it appears a growing trend is 
> the spamming of blogs.  With Geeklog a big player in this arena I 
> think we would be wise to start thinking up ways to implement anti-
> spam measures.
> 
> I think the start would be to be able to mark comments as spam.  
> When a comment is identified as spam I think the IP should be 
> logged.  In the config.php file I think we could then set a spam 
> threshold at say 5. What that means is if a an IP is tied to 
> spamming the Geeklog site five times then we would ban that IP.  I 
> know using IP's isn't the greatest but my hunch is 99% of this sort 
> of spam would come from static IP's and not proxy IP's.  However, we 
> should still allow admins to turn this feature on or off.
> 
> One other bit of useful logic would be to check if the source IP of 
> spam has been tied to comments which weren't identified as spam.  If 
> we did that then in our logic we could basically check a) has the IP 
> hit the threshold, if so has it been used in non-spam comments.  If 
> it *has* been used in non-spam comments then we could assume it is 
> from a proxied IP and not ban the IP.
> 
> I also think later versions of this could use MySQL's full text 
> searching capabilities.
> 
> To start, if we were to add the IP to the comment table I think we 
> could write a plugin to do all this.  OF course this assumes that a 
> plugin API is called when a comment is submitted which may or may 
> not be the case ( I can't remember).
> 
> I'm sure you guys may have other ideas too.
> 
> -- 
> +--------------------------------------------------------------------
> --+ |Tony Bibbs         |[R]egardless of what you may think of our 
> penal   | |tony at tonybibbs.com |system, the fact is that every man in 
> jail is one | |                   |less potential fisherman to 
> clutter up your       | |                   |favorite pool or pond. -
> -Ed Zern                  | +----------------------------------------
> ------------------------------+
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From vmf at abtech.org  Tue Oct 28 11:50:30 2003
From: vmf at abtech.org (Vincent Furia)
Date: Tue, 28 Oct 2003 08:50:30 -0800
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <20031028155706.M5829@pigstye.net>
References: <3F9E869D.5070508@tonybibbs.com> <20031028155706.M5829@pigstye.net>
Message-ID: <3F9E9E56.7070301@abtech.org>

One thing I'd recommend is rather than a total ban on an IP address, at 
least initially, only ban anonymous users from posting comments.  Then 
you can ban from there based on email address/username.  And then only 
as a last resort ban all comments from an IP address.

-Vinny

Tom Willett wrote:

>Add the ip to the comments in geeklog and my ban plugin could easily handle 
>the rest.  
>
>All I would have to do is add the logic to check for the repeated spam 
>comments.
>
>
>--
>Tom Willett
>tomw at pigstye.net
>
>---------- Original Message -----------
>From: Tony Bibbs <tony at tonybibbs.com>
>To: Geeklog Development <geeklog-devel at lists.geeklog.net>
>Sent: Tue, 28 Oct 2003 09:09:17 -0600
>Subject: [geeklog-devel] Anti Spam Features
>
>  
>
>>As noted in the forums of Geeklog.net it appears a growing trend is 
>>the spamming of blogs.  With Geeklog a big player in this arena I 
>>think we would be wise to start thinking up ways to implement anti-
>>spam measures.
>>
>>I think the start would be to be able to mark comments as spam.  
>>When a comment is identified as spam I think the IP should be 
>>logged.  In the config.php file I think we could then set a spam 
>>threshold at say 5. What that means is if a an IP is tied to 
>>spamming the Geeklog site five times then we would ban that IP.  I 
>>know using IP's isn't the greatest but my hunch is 99% of this sort 
>>of spam would come from static IP's and not proxy IP's.  However, we 
>>should still allow admins to turn this feature on or off.
>>
>>One other bit of useful logic would be to check if the source IP of 
>>spam has been tied to comments which weren't identified as spam.  If 
>>we did that then in our logic we could basically check a) has the IP 
>>hit the threshold, if so has it been used in non-spam comments.  If 
>>it *has* been used in non-spam comments then we could assume it is 
>>from a proxied IP and not ban the IP.
>>
>>I also think later versions of this could use MySQL's full text 
>>searching capabilities.
>>
>>To start, if we were to add the IP to the comment table I think we 
>>could write a plugin to do all this.  OF course this assumes that a 
>>plugin API is called when a comment is submitted which may or may 
>>not be the case ( I can't remember).
>>
>>I'm sure you guys may have other ideas too.
>>
>>-- 
>>+--------------------------------------------------------------------
>>--+ |Tony Bibbs         |[R]egardless of what you may think of our 
>>penal   | |tony at tonybibbs.com |system, the fact is that every man in 
>>jail is one | |                   |less potential fisherman to 
>>clutter up your       | |                   |favorite pool or pond. -
>>-Ed Zern                  | +----------------------------------------
>>------------------------------+
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>    
>>
>------- End of Original Message -------
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>  
>




From tony at tonybibbs.com  Tue Oct 28 12:18:47 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 28 Oct 2003 11:18:47 -0600
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <3F9E9E56.7070301@abtech.org>
References: <3F9E869D.5070508@tonybibbs.com> <20031028155706.M5829@pigstye.net> <3F9E9E56.7070301@abtech.org>
Message-ID: <3F9EA4F7.90202@tonybibbs.com>

Yeah, obviously you would start by banning anonymous comments.  What I 
was after is the more difficult use case of admins who want to allow 
anonymous comments yet prevent spam.  Good clarification though as, 
obviously, banning a username is much easier and reliable to do than an 
IP.

Vincent Furia wrote:
> One thing I'd recommend is rather than a total ban on an IP address, at 
> least initially, only ban anonymous users from posting comments.  Then 
> you can ban from there based on email address/username.  And then only 
> as a last resort ban all comments from an IP address.
> 
> -Vinny
> 
> Tom Willett wrote:
> 
>> Add the ip to the comments in geeklog and my ban plugin could easily 
>> handle the rest. 
>> All I would have to do is add the logic to check for the repeated spam 
>> comments.
>>
>>
>> -- 
>> Tom Willett
>> tomw at pigstye.net
>>
>> ---------- Original Message -----------
>> From: Tony Bibbs <tony at tonybibbs.com>
>> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
>> Sent: Tue, 28 Oct 2003 09:09:17 -0600
>> Subject: [geeklog-devel] Anti Spam Features
>>
>>  
>>
>>> As noted in the forums of Geeklog.net it appears a growing trend is 
>>> the spamming of blogs.  With Geeklog a big player in this arena I 
>>> think we would be wise to start thinking up ways to implement anti-
>>> spam measures.
>>>
>>> I think the start would be to be able to mark comments as spam.  When 
>>> a comment is identified as spam I think the IP should be logged.  In 
>>> the config.php file I think we could then set a spam threshold at say 
>>> 5. What that means is if a an IP is tied to spamming the Geeklog site 
>>> five times then we would ban that IP.  I know using IP's isn't the 
>>> greatest but my hunch is 99% of this sort of spam would come from 
>>> static IP's and not proxy IP's.  However, we should still allow 
>>> admins to turn this feature on or off.
>>>
>>> One other bit of useful logic would be to check if the source IP of 
>>> spam has been tied to comments which weren't identified as spam.  If 
>>> we did that then in our logic we could basically check a) has the IP 
>>> hit the threshold, if so has it been used in non-spam comments.  If 
>>> it *has* been used in non-spam comments then we could assume it is 
>>> from a proxied IP and not ban the IP.
>>>
>>> I also think later versions of this could use MySQL's full text 
>>> searching capabilities.
>>>
>>> To start, if we were to add the IP to the comment table I think we 
>>> could write a plugin to do all this.  OF course this assumes that a 
>>> plugin API is called when a comment is submitted which may or may not 
>>> be the case ( I can't remember).
>>>
>>> I'm sure you guys may have other ideas too.
>>>
>>> -- 
>>> +--------------------------------------------------------------------
>>> --+ |Tony Bibbs         |[R]egardless of what you may think of our 
>>> penal   | |tony at tonybibbs.com |system, the fact is that every man in 
>>> jail is one | |                   |less potential fisherman to 
>>> clutter up your       | |                   |favorite pool or pond. -
>>> -Ed Zern                  | +----------------------------------------
>>> ------------------------------+
>>>
>>> _______________________________________________
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>   
>>
>> ------- End of Original Message -------
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>  
>>
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From vmf at abtech.org  Tue Oct 28 12:39:45 2003
From: vmf at abtech.org (Vincent Furia)
Date: Tue, 28 Oct 2003 09:39:45 -0800
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <3F9EA4F7.90202@tonybibbs.com>
References: <3F9E869D.5070508@tonybibbs.com> <20031028155706.M5829@pigstye.net> <3F9E9E56.7070301@abtech.org> <3F9EA4F7.90202@tonybibbs.com>
Message-ID: <3F9EA9E1.6030009@abtech.org>

Sorry, I wasn't too clear.  What I meant was to initially ban only 
anonymous comments from an IP that is spamming the comments (with the 
assumption most spammers won't go through the trouble of spamming).  
This could be implmented on the first spam recieved and would hopefully 
limit the trouble caused by spammers behind large proxies (like AOL).  
If a spammer does register, then you can block by username/email.  And 
if you have a really persistant, pain in the ass spammer, then you can 
completely block by IP.  This way an admin can allow anonymous comments 
generally, but block anonymous comments from specific IPs.

I'd also note that it may be a good idea to tie this in with Geeklog's 
ability to send emails (i.e. a banned IP won't be able to submit 
comments or send email to site users).

This may be exactly what you were already talking about, but I just 
wanted to make sure I was clear on it.

-Vinny

Tony Bibbs wrote:

> Yeah, obviously you would start by banning anonymous comments.  What I 
> was after is the more difficult use case of admins who want to allow 
> anonymous comments yet prevent spam.  Good clarification though as, 
> obviously, banning a username is much easier and reliable to do than 
> an IP.
>
> Vincent Furia wrote:
>
>> One thing I'd recommend is rather than a total ban on an IP address, 
>> at least initially, only ban anonymous users from posting comments.  
>> Then you can ban from there based on email address/username.  And 
>> then only as a last resort ban all comments from an IP address.
>>
>> -Vinny
>>
>> Tom Willett wrote:
>>
>>> Add the ip to the comments in geeklog and my ban plugin could easily 
>>> handle the rest. All I would have to do is add the logic to check 
>>> for the repeated spam comments.
>>>
>>>
>>> -- 
>>> Tom Willett
>>> tomw at pigstye.net
>>>
>>> ---------- Original Message -----------
>>> From: Tony Bibbs <tony at tonybibbs.com>
>>> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
>>> Sent: Tue, 28 Oct 2003 09:09:17 -0600
>>> Subject: [geeklog-devel] Anti Spam Features
>>>
>>>  
>>>
>>>> As noted in the forums of Geeklog.net it appears a growing trend is 
>>>> the spamming of blogs.  With Geeklog a big player in this arena I 
>>>> think we would be wise to start thinking up ways to implement anti-
>>>> spam measures.
>>>>
>>>> I think the start would be to be able to mark comments as spam.  
>>>> When a comment is identified as spam I think the IP should be 
>>>> logged.  In the config.php file I think we could then set a spam 
>>>> threshold at say 5. What that means is if a an IP is tied to 
>>>> spamming the Geeklog site five times then we would ban that IP.  I 
>>>> know using IP's isn't the greatest but my hunch is 99% of this sort 
>>>> of spam would come from static IP's and not proxy IP's.  However, 
>>>> we should still allow admins to turn this feature on or off.
>>>>
>>>> One other bit of useful logic would be to check if the source IP of 
>>>> spam has been tied to comments which weren't identified as spam.  
>>>> If we did that then in our logic we could basically check a) has 
>>>> the IP hit the threshold, if so has it been used in non-spam 
>>>> comments.  If it *has* been used in non-spam comments then we could 
>>>> assume it is from a proxied IP and not ban the IP.
>>>>
>>>> I also think later versions of this could use MySQL's full text 
>>>> searching capabilities.
>>>>
>>>> To start, if we were to add the IP to the comment table I think we 
>>>> could write a plugin to do all this.  OF course this assumes that a 
>>>> plugin API is called when a comment is submitted which may or may 
>>>> not be the case ( I can't remember).
>>>>
>>>> I'm sure you guys may have other ideas too.
>>>>
>>>> -- 
>>>> +--------------------------------------------------------------------
>>>> --+ |Tony Bibbs         |[R]egardless of what you may think of our 
>>>> penal   | |tony at tonybibbs.com |system, the fact is that every man 
>>>> in jail is one | |                   |less potential fisherman to 
>>>> clutter up your       | |                   |favorite pool or pond. -
>>>> -Ed Zern                  | +----------------------------------------
>>>> ------------------------------+
>>>>
>>>> _______________________________________________
>>>> geeklog-devel mailing list
>>>> geeklog-devel at lists.geeklog.net
>>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>>   
>>>
>>>
>>> ------- End of Original Message -------
>>>
>>> _______________________________________________
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>  
>>>
>>
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>
>




From tony at tonybibbs.com  Tue Oct 28 13:09:49 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 28 Oct 2003 12:09:49 -0600
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <3F9EA9E1.6030009@abtech.org>
References: <3F9E869D.5070508@tonybibbs.com> <20031028155706.M5829@pigstye.net> <3F9E9E56.7070301@abtech.org> <3F9EA4F7.90202@tonybibbs.com> <3F9EA9E1.6030009@abtech.org>
Message-ID: <3F9EB0ED.5080709@tonybibbs.com>

No actually that isn't quite what I was getting at.  What you just said 
makes a lot of sense.

Vincent Furia wrote:
> Sorry, I wasn't too clear.  What I meant was to initially ban only 
> anonymous comments from an IP that is spamming the comments (with the 
> assumption most spammers won't go through the trouble of spamming).  
> This could be implmented on the first spam recieved and would hopefully 
> limit the trouble caused by spammers behind large proxies (like AOL).  
> If a spammer does register, then you can block by username/email.  And 
> if you have a really persistant, pain in the ass spammer, then you can 
> completely block by IP.  This way an admin can allow anonymous comments 
> generally, but block anonymous comments from specific IPs.
> 
> I'd also note that it may be a good idea to tie this in with Geeklog's 
> ability to send emails (i.e. a banned IP won't be able to submit 
> comments or send email to site users).
> 
> This may be exactly what you were already talking about, but I just 
> wanted to make sure I was clear on it.
> 
> -Vinny
> 
> Tony Bibbs wrote:
> 
>> Yeah, obviously you would start by banning anonymous comments.  What I 
>> was after is the more difficult use case of admins who want to allow 
>> anonymous comments yet prevent spam.  Good clarification though as, 
>> obviously, banning a username is much easier and reliable to do than 
>> an IP.
>>
>> Vincent Furia wrote:
>>
>>> One thing I'd recommend is rather than a total ban on an IP address, 
>>> at least initially, only ban anonymous users from posting comments.  
>>> Then you can ban from there based on email address/username.  And 
>>> then only as a last resort ban all comments from an IP address.
>>>
>>> -Vinny
>>>
>>> Tom Willett wrote:
>>>
>>>> Add the ip to the comments in geeklog and my ban plugin could easily 
>>>> handle the rest. All I would have to do is add the logic to check 
>>>> for the repeated spam comments.
>>>>
>>>>
>>>> -- 
>>>> Tom Willett
>>>> tomw at pigstye.net
>>>>
>>>> ---------- Original Message -----------
>>>> From: Tony Bibbs <tony at tonybibbs.com>
>>>> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
>>>> Sent: Tue, 28 Oct 2003 09:09:17 -0600
>>>> Subject: [geeklog-devel] Anti Spam Features
>>>>
>>>>  
>>>>
>>>>> As noted in the forums of Geeklog.net it appears a growing trend is 
>>>>> the spamming of blogs.  With Geeklog a big player in this arena I 
>>>>> think we would be wise to start thinking up ways to implement anti-
>>>>> spam measures.
>>>>>
>>>>> I think the start would be to be able to mark comments as spam.  
>>>>> When a comment is identified as spam I think the IP should be 
>>>>> logged.  In the config.php file I think we could then set a spam 
>>>>> threshold at say 5. What that means is if a an IP is tied to 
>>>>> spamming the Geeklog site five times then we would ban that IP.  I 
>>>>> know using IP's isn't the greatest but my hunch is 99% of this sort 
>>>>> of spam would come from static IP's and not proxy IP's.  However, 
>>>>> we should still allow admins to turn this feature on or off.
>>>>>
>>>>> One other bit of useful logic would be to check if the source IP of 
>>>>> spam has been tied to comments which weren't identified as spam.  
>>>>> If we did that then in our logic we could basically check a) has 
>>>>> the IP hit the threshold, if so has it been used in non-spam 
>>>>> comments.  If it *has* been used in non-spam comments then we could 
>>>>> assume it is from a proxied IP and not ban the IP.
>>>>>
>>>>> I also think later versions of this could use MySQL's full text 
>>>>> searching capabilities.
>>>>>
>>>>> To start, if we were to add the IP to the comment table I think we 
>>>>> could write a plugin to do all this.  OF course this assumes that a 
>>>>> plugin API is called when a comment is submitted which may or may 
>>>>> not be the case ( I can't remember).
>>>>>
>>>>> I'm sure you guys may have other ideas too.
>>>>>
>>>>> -- 
>>>>> +--------------------------------------------------------------------
>>>>> --+ |Tony Bibbs         |[R]egardless of what you may think of our 
>>>>> penal   | |tony at tonybibbs.com |system, the fact is that every man 
>>>>> in jail is one | |                   |less potential fisherman to 
>>>>> clutter up your       | |                   |favorite pool or pond. -
>>>>> -Ed Zern                  | +----------------------------------------
>>>>> ------------------------------+
>>>>>
>>>>> _______________________________________________
>>>>> geeklog-devel mailing list
>>>>> geeklog-devel at lists.geeklog.net
>>>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>>>   
>>>>
>>>>
>>>>
>>>> ------- End of Original Message -------
>>>>
>>>> _______________________________________________
>>>> geeklog-devel mailing list
>>>> geeklog-devel at lists.geeklog.net
>>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>>
>>>>  
>>>>
>>>
>>>
>>> _______________________________________________
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From dirk at haun-online.de  Tue Oct 28 13:43:03 2003
From: dirk at haun-online.de (Dirk Haun)
Date: Tue, 28 Oct 2003 19:43:03 +0100
Subject: [geeklog-devel] Anti Spam Features
In-Reply-To: <3F9EA9E1.6030009@abtech.org>
References: <3F9EA9E1.6030009@abtech.org>
Message-ID: <20031028184303.29630@smtp.haun-online.de>

Seven quick tips for a spam-free blog
http://cheerleader.yoz.com/archives/000849.html

bye, Dirk


-- 
http://www.haun-online.de/
http://www.macosx-faq.de/



From tony at tonybibbs.com  Wed Oct 29 17:55:21 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 29 Oct 2003 16:55:21 -0600
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates
 to the API
Message-ID: <3FA04559.5080004@tonybibbs.com>

I wanted to draw an ascii picture of what GL2 has started or planned so 
far.  Please take note as this impacts some of our discussions of late:

----------------------------------------------------------
|         | AUTHENTICATION/AUTHORIZATION |                |-->Module 1
| Geeklog | TRANSLATION                  | Plugin Manager |-->Module 2
|         | messaging*                   | (Includes API) |-->Module 3
|         | SESSION MANAGEMENT           |                |-->Module N
|         | database abstraction         |                |
|         | MVC                          |                |
|         | SPELLCHECKER                 |                |
|         | up2date service*             |                |
|         | module library interface     |                |
|         | remote bug reporting         |                |
|         | etc.                         |                |
-----------------------------------------------------------

NOTE: items in all CAPS have either been implemented or are being 
implemented.  Items marked with an * are items that would be for-profit 
or have extended for-profit features.

The diagram above isn't radically different from how GL 1.3.x works (I 
mean, we did do a lot of good stuff that shoud carry over).  First the 
big box containing the three sections is how we can logically think of 
Geeklog.  The middle tier are classes that I would provide a key 
resource to all modules.  The Plugin manager is the means by which 
Geeklog communicates to all the modules (the equivalent of 
lib-plugins.php in the 1.3.x world).

First off, Blaine, notice how I have made your messaging portion part of 
the core.  I know you don't want this but keep in mind this is a logical 
representation, not a physical on.  I plan on making your messaging 
component a true module.  The distinction is that I think you can almost 
gaurantee that nearly all modules will want the ability to use 
messaging.  Also, for clarity when I say messaging I a lumping PM, IM 
and Email functions all together.

Now let me bring your attention to the Plugin Manager.  This portion 
consists of two distinct pieces.  A) the server side manager responsible 
for calling API methods on the modules and B) the API itself that all 
modules must implement.

The API that vinny was talking about is item B) above.  I make this 
clarification because as I read through some of the feedback I saw us 
talking about things that aren't really meant to be in the API (note 
Vinny mentioned the same thing in his last message).  To be clear, the 
API should consist of methods that GL would want to all in order to 
invoke some sort of processing from a module.  On the flip side, the 
Plugin Manager will proxy requests between Geeklog and the modules (this 
IS a two way street).

That being said, we should probably be working on both the Module API 
*and* the object model for the Plugin Manager since they are so closely 
related.

On a side note, anything in lowercase has not been started yet.  If 
anybody wants to volunteer or any of those pieces please let me know.

Finally, I am hoping we find a new name for this other than "Geeklog". 
I know we have talked about this a lot but I wanted to bring this back 
up and challenge us to find a name that is a) catchy and b) marketable 
to businesses.

--Tony

+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From geeklog at langfamily.ca  Wed Oct 29 19:38:03 2003
From: geeklog at langfamily.ca (Blaine Lang)
Date: Wed, 29 Oct 2003 19:38:03 -0500
Subject: [geeklog-devel] Anti Spam Features
References: <3F9EA9E1.6030009@abtech.org> <20031028184303.29630@smtp.haun-online.de>
Message-ID: <005a01c39e7e$142b8450$9a0a10ac@xpbl1>

Thanks Dirk,

Some interesting ideas that can be considered but also the site had other
interesting content and links.

Blaine
----- Original Message -----
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, October 28, 2003 1:43 PM
Subject: Re: [geeklog-devel] Anti Spam Features


> Seven quick tips for a spam-free blog
> http://cheerleader.yoz.com/archives/000849.html
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://www.macosx-faq.de/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From geeklog at langfamily.ca  Wed Oct 29 19:38:45 2003
From: geeklog at langfamily.ca (Blaine Lang)
Date: Wed, 29 Oct 2003 19:38:45 -0500
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API
References: <3FA04559.5080004@tonybibbs.com>
Message-ID: <006001c39e7e$2d515a40$9a0a10ac@xpbl1>

Tony,

I'd like to take a crack at putting together a drawing that puts this into
pictures.
Give me a few days.

Blaine
----- Original Message -----
From: "Tony Bibbs" <tony at tonybibbs.com>
To: "Geeklog Development" <geeklog-devel at lists.geeklog.net>
Sent: Wednesday, October 29, 2003 5:55 PM
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and
how it relates to the API


> I wanted to draw an ascii picture of what GL2 has started or planned so
> far.  Please take note as this impacts some of our discussions of late:
>
> ----------------------------------------------------------
> |         | AUTHENTICATION/AUTHORIZATION |                |-->Module 1
> | Geeklog | TRANSLATION                  | Plugin Manager |-->Module 2
> |         | messaging*                   | (Includes API) |-->Module 3
> |         | SESSION MANAGEMENT           |                |-->Module N
> |         | database abstraction         |                |
> |         | MVC                          |                |
> |         | SPELLCHECKER                 |                |
> |         | up2date service*             |                |
> |         | module library interface     |                |
> |         | remote bug reporting         |                |
> |         | etc.                         |                |
> -----------------------------------------------------------
>
> NOTE: items in all CAPS have either been implemented or are being
> implemented.  Items marked with an * are items that would be for-profit
> or have extended for-profit features.
>
> The diagram above isn't radically different from how GL 1.3.x works (I
> mean, we did do a lot of good stuff that shoud carry over).  First the
> big box containing the three sections is how we can logically think of
> Geeklog.  The middle tier are classes that I would provide a key
> resource to all modules.  The Plugin manager is the means by which
> Geeklog communicates to all the modules (the equivalent of
> lib-plugins.php in the 1.3.x world).
>
> First off, Blaine, notice how I have made your messaging portion part of
> the core.  I know you don't want this but keep in mind this is a logical
> representation, not a physical on.  I plan on making your messaging
> component a true module.  The distinction is that I think you can almost
> gaurantee that nearly all modules will want the ability to use
> messaging.  Also, for clarity when I say messaging I a lumping PM, IM
> and Email functions all together.
>
> Now let me bring your attention to the Plugin Manager.  This portion
> consists of two distinct pieces.  A) the server side manager responsible
> for calling API methods on the modules and B) the API itself that all
> modules must implement.
>
> The API that vinny was talking about is item B) above.  I make this
> clarification because as I read through some of the feedback I saw us
> talking about things that aren't really meant to be in the API (note
> Vinny mentioned the same thing in his last message).  To be clear, the
> API should consist of methods that GL would want to all in order to
> invoke some sort of processing from a module.  On the flip side, the
> Plugin Manager will proxy requests between Geeklog and the modules (this
> IS a two way street).
>
> That being said, we should probably be working on both the Module API
> *and* the object model for the Plugin Manager since they are so closely
> related.
>
> On a side note, anything in lowercase has not been started yet.  If
> anybody wants to volunteer or any of those pieces please let me know.
>
> Finally, I am hoping we find a new name for this other than "Geeklog".
> I know we have talked about this a lot but I wanted to bring this back
> up and challenge us to find a name that is a) catchy and b) marketable
> to businesses.
>
> --Tony
>
> +----------------------------------------------------------------------+
> |Tony Bibbs         |[R]egardless of what you may think of our penal   |
> |tony at tonybibbs.com |system, the fact is that every man in jail is one |
> |                   |less potential fisherman to clutter up your       |
> |                   |favorite pool or pond. --Ed Zern                  |
> +----------------------------------------------------------------------+
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From tomw at pigstye.net  Thu Oct 30 08:41:26 2003
From: tomw at pigstye.net (Tom Willett)
Date: Thu, 30 Oct 2003 13:41:26 +0000
Subject: [geeklog-devel] New Plugin Wish
Message-ID: <20031030132815.M81674@pigstye.net>

I just ran across an issue that it would be nice for Geeklog 2 to address.  
Tony I imagine that this should be taken in to account in session 
management.  

It would be nice to have a simple way to pass state information.  HTTP being 
a stateless protocol we have to resort to either cookies or passing 
everything as post or get variables or some such mechanism.  I am against 
plugins/addons adding extra cookies and from a security and aesthetic 
standpoint do not like to use get variables unless necessary.  Plugins can 
do this on their own by using the database for a scratch area, but this then 
requires another database access for each plugin.

Just a thought that if implemented could make programming plugins easier and 
more secure.

--
Tom Willett
tomw at pigstye.net



From tony at tonybibbs.com  Thu Oct 30 09:27:57 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 30 Oct 2003 08:27:57 -0600
Subject: [geeklog-devel] New Plugin Wish
In-Reply-To: <20031030132815.M81674@pigstye.net>
References: <20031030132815.M81674@pigstye.net>
Message-ID: <3FA11FED.8030602@tonybibbs.com>

You are right, our custom PHP session handler will allow plugins to pass 
data around.

If you want to have a value (or object) just add it to the $_SESSION 
superglobal:

$user = &AEService::Authenticate($userName, $password);
$_SESSION['user'] = $user;

Then on subsequent page requests you would have access to the user 
object in the session.  Please note if you put objects in session the 
class definition needs to be included before you bring it out of the 
session.  Also, for GL2 we will need to set some ground rules on what 
can go in the session.  Sessions sizes should be measured in KB not MB.

Hope that helps,

--Tony

Tom Willett wrote:
> I just ran across an issue that it would be nice for Geeklog 2 to address.  
> Tony I imagine that this should be taken in to account in session 
> management.  
> 
> It would be nice to have a simple way to pass state information.  HTTP being 
> a stateless protocol we have to resort to either cookies or passing 
> everything as post or get variables or some such mechanism.  I am against 
> plugins/addons adding extra cookies and from a security and aesthetic 
> standpoint do not like to use get variables unless necessary.  Plugins can 
> do this on their own by using the database for a scratch area, but this then 
> requires another database access for each plugin.
> 
> Just a thought that if implemented could make programming plugins easier and 
> more secure.
> 
> --
> Tom Willett
> tomw at pigstye.net
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From tomw at pigstye.net  Thu Oct 30 12:02:41 2003
From: tomw at pigstye.net (Tom Willett)
Date: Thu, 30 Oct 2003 17:02:41 +0000
Subject: [geeklog-devel] New Plugin Wish
In-Reply-To: <3FA11FED.8030602@tonybibbs.com>
References: <20031030132815.M81674@pigstye.net> <3FA11FED.8030602@tonybibbs.com>
Message-ID: <20031030163528.M3995@pigstye.net>

> You are right, our custom PHP session handler will allow plugins to pass 
> data around.
> 
> If you want to have a value (or object) just add it to the $_SESSION 
> superglobal:
> 
> $user = &AEService::Authenticate($userName, $password);
> $_SESSION['user'] = $user;
> 
> Then on subsequent page requests you would have access to the user 
> object in the session.  Please note if you put objects in session the 
> class definition needs to be included before you bring it out of the 
> session.  Also, for GL2 we will need to set some ground rules on what 
> can go in the session.  Sessions sizes should be measured in KB not MB.
> 
> Hope that helps,
> 
> --Tony
> 
Perfect, just what I was thinking of, that should make things easier and 
cleaner.  This would allow a user (even anonymous) to set options that would 
only be valid for their current session and allow the plugin to maintain 
state even when control is passed elsewhere.

And I will agree that we need to keep sessions small -- we also should have 
some guidelines about variable naming in sessions.  We don't want multiple 
plugins stuffing things in the same variable like 'user'.

A question about your session handler.  If I have a session open and follow 
a link with shift-click do both windows share the have the same session?  (I 
ran into this issue with an webmail program.)

TomW


From tony at tonybibbs.com  Thu Oct 30 13:33:38 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 30 Oct 2003 12:33:38 -0600
Subject: [geeklog-devel] New Plugin Wish
In-Reply-To: <20031030163528.M3995@pigstye.net>
References: <20031030132815.M81674@pigstye.net> <3FA11FED.8030602@tonybibbs.com> <20031030163528.M3995@pigstye.net>
Message-ID: <3FA15982.9080502@tonybibbs.com>

Both windows would share the same session.


Tom Willett wrote:
>>You are right, our custom PHP session handler will allow plugins to pass 
>>data around.
>>
>>If you want to have a value (or object) just add it to the $_SESSION 
>>superglobal:
>>
>>$user = &AEService::Authenticate($userName, $password);
>>$_SESSION['user'] = $user;
>>
>>Then on subsequent page requests you would have access to the user 
>>object in the session.  Please note if you put objects in session the 
>>class definition needs to be included before you bring it out of the 
>>session.  Also, for GL2 we will need to set some ground rules on what 
>>can go in the session.  Sessions sizes should be measured in KB not MB.
>>
>>Hope that helps,
>>
>>--Tony
>>
> 
> Perfect, just what I was thinking of, that should make things easier and 
> cleaner.  This would allow a user (even anonymous) to set options that would 
> only be valid for their current session and allow the plugin to maintain 
> state even when control is passed elsewhere.
> 
> And I will agree that we need to keep sessions small -- we also should have 
> some guidelines about variable naming in sessions.  We don't want multiple 
> plugins stuffing things in the same variable like 'user'.
> 
> A question about your session handler.  If I have a session open and follow 
> a link with shift-click do both windows share the have the same session?  (I 
> ran into this issue with an webmail program.)
> 
> TomW
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+



From vmf at abtech.org  Fri Oct 31 14:43:34 2003
From: vmf at abtech.org (Vincent Furia)
Date: Fri, 31 Oct 2003 11:43:34 -0800
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far
 and how it relates to the API
In-Reply-To: <3FA04559.5080004@tonybibbs.com>
References: <3FA04559.5080004@tonybibbs.com>
Message-ID: <3FA2BB66.6040505@abtech.org>

A couple comments I wanted to add about plugins and other GL2 stuff.  
First, I think that we should consider making some of the 'core' 
functionality into plugins instead. Specifically I'm referring to the 
comment engine, the (potential) ratings engine, and the messaging system 
(maybe even the logging system?).  This would allow users to replace the 
functionality provided by these plugins.  A good example of this might 
be replacing a standard comment system with a forum-like comment 
system.  I think doing so would give GL2 even more flexibility.

I know Tony didn't mean the core feautre list to be exhaustive, but one 
item I didn't see (but would like to see) was a configuration utility.  
I think, with GL2, we should get away from forcing GL administrators 
from editing config.php by hand and move to a fully web based 
configuration utility that can be used by the plugins as well being used 
for core feautres.

On that subject I think it's time to start putting together a document 
that shows what core functionality GL2 will provide and any information 
we have on how it will provide that.  Something like a design document.  
It's something that I'd be willing to work on, but I'd need a lot of 
information and support, especially from Tony.  Maybe this is something 
that would best be done in a Wiki format?

Finally, I have a few comments about event handling system and a few 
comments on plugins in general.  If we do this well, and efficiently, we 
could have a really flexible, extensible system that will beat out every 
other open source system I've seen.  For that reason I think its 
important to focus, briefly on how the plugin event calls might work in 
GL2.  This is just a rough idea, and I'd really like to see input on 
what you all think of this.

Each plugin should be able to register the fact it wants to be called 
when certain events occur:
    registerEventCallback(plugin registering callback, plugin raising 
event, event)

Then, a plugin can notify GL2 that event has occurred with:
    raiseEvent(plugin raising event, event, parameters)   // parameters: 
array of values

Upon being notified that an event occurred, GL2 can call the plugin API 
for all plugins registered to recieve the event:
    onEvent(plugin raising event, event, parameters)

Also plugins need to be able to invoke an event/function in another plugin:
    invokeEvent(plugin providing function, event, parameters)

I'm still thinking about possible ways raiseEvent and invokeEvent can 
handle returned values. One possibility, at least for invokeEvent, is 
the functions could be required to return a small object containing 
status (-1, failure; 0, plugin function not found; 1, success; etc.) and 
the results of the call:
    $P = invokeEvent(plugin, event, parameters);
     if ($P->status > 0) {
         echo $P->result;
     }

Of course all this leads to a question if we should have a severely 
simplified API where even core functionality such as the moderation 
fuctions, comment functions, etc should all be called through this event 
API (with a plugin name = 'core').  One advantage to doing it this way 
would allow us to extend plugin functionality in later releases without 
affecting the plugin API (which would prevent plugin obsolesence to an 
extent).

Another issue I think we should start talking about is plugin 
dependency, and how to handle it gracefully.  Obviously plugins will 
support, to one extent or another, the use of other plugins.  This could 
run the gambit from a plugin being dependent on another plugin to work, 
to a plugin using another plugin in a non dependent way (i.e. the plugin 
isn't required for operation, just for extended functionality).

I think that is more than enough to digest in one sitting.  If anyone 
would like to chat with me I'll try to be available in #geeklog.  Of 
couse, email discourse is always welcome as well.

-Vinny
Who is already having fun...



From geeklog at langfamily.ca  Fri Oct 31 16:34:25 2003
From: geeklog at langfamily.ca (Blaine Lang)
Date: Fri, 31 Oct 2003 16:34:25 -0500
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API
References: <3FA04559.5080004@tonybibbs.com> <3FA2BB66.6040505@abtech.org>
Message-ID: <001601c39ff6$c1b76a20$9a0a10ac@xpbl1>

Vincent,

I've just been reading up on the PostNuke API as I have a module that I need
to develop for a client. This is not Nuke but a totally separate development
effort (for those that are not aware). A lot of what you raise was raising
the same ideas for me as I was reading their module developer and API
documents.

http://noc.postnuke.com/docman/view.php/5/10/pnAPI.htm

Their API is still in development but already has some of the ideas you
presented.
There are a lot of other API's here that we use COM functions or Globals
for. In GL2, we will not be relying on globals so there will be a need for
some of these API or functions to be exposed.

I expect GL2 will be if not 100% OO - very close and I believe PostNuke (
next step for me is to look at their code) is all OO. So this API reference
may be helpfull.
http://noc.postnuke.com/docman/view.php/5/10/pnAPI.html#id2758765

Blaine

----- Original Message -----
From: "Vincent Furia" <vmf at abtech.org>
To: <geeklog-devel at lists.geeklog.net>
Sent: Friday, October 31, 2003 2:43 PM
Subject: Re: [geeklog-devel] Quick overview of GL2 and what we have so far
and how it relates to the API


> A couple comments I wanted to add about plugins and other GL2 stuff.
> First, I think that we should consider making some of the 'core'
> functionality into plugins instead. Specifically I'm referring to the
> comment engine, the (potential) ratings engine, and the messaging system
> (maybe even the logging system?).  This would allow users to replace the
> functionality provided by these plugins.  A good example of this might
> be replacing a standard comment system with a forum-like comment
> system.  I think doing so would give GL2 even more flexibility.
>
> I know Tony didn't mean the core feautre list to be exhaustive, but one
> item I didn't see (but would like to see) was a configuration utility.
> I think, with GL2, we should get away from forcing GL administrators
> from editing config.php by hand and move to a fully web based
> configuration utility that can be used by the plugins as well being used
> for core feautres.
>
> On that subject I think it's time to start putting together a document
> that shows what core functionality GL2 will provide and any information
> we have on how it will provide that.  Something like a design document.
> It's something that I'd be willing to work on, but I'd need a lot of
> information and support, especially from Tony.  Maybe this is something
> that would best be done in a Wiki format?
>
> Finally, I have a few comments about event handling system and a few
> comments on plugins in general.  If we do this well, and efficiently, we
> could have a really flexible, extensible system that will beat out every
> other open source system I've seen.  For that reason I think its
> important to focus, briefly on how the plugin event calls might work in
> GL2.  This is just a rough idea, and I'd really like to see input on
> what you all think of this.
>
> Each plugin should be able to register the fact it wants to be called
> when certain events occur:
>     registerEventCallback(plugin registering callback, plugin raising
> event, event)
>
> Then, a plugin can notify GL2 that event has occurred with:
>     raiseEvent(plugin raising event, event, parameters)   // parameters:
> array of values
>
> Upon being notified that an event occurred, GL2 can call the plugin API
> for all plugins registered to recieve the event:
>     onEvent(plugin raising event, event, parameters)
>
> Also plugins need to be able to invoke an event/function in another
plugin:
>     invokeEvent(plugin providing function, event, parameters)
>
> I'm still thinking about possible ways raiseEvent and invokeEvent can
> handle returned values. One possibility, at least for invokeEvent, is
> the functions could be required to return a small object containing
> status (-1, failure; 0, plugin function not found; 1, success; etc.) and
> the results of the call:
>     $P = invokeEvent(plugin, event, parameters);
>      if ($P->status > 0) {
>          echo $P->result;
>      }
>
> Of course all this leads to a question if we should have a severely
> simplified API where even core functionality such as the moderation
> fuctions, comment functions, etc should all be called through this event
> API (with a plugin name = 'core').  One advantage to doing it this way
> would allow us to extend plugin functionality in later releases without
> affecting the plugin API (which would prevent plugin obsolesence to an
> extent).
>
> Another issue I think we should start talking about is plugin
> dependency, and how to handle it gracefully.  Obviously plugins will
> support, to one extent or another, the use of other plugins.  This could
> run the gambit from a plugin being dependent on another plugin to work,
> to a plugin using another plugin in a non dependent way (i.e. the plugin
> isn't required for operation, just for extended functionality).
>
> I think that is more than enough to digest in one sitting.  If anyone
> would like to chat with me I'll try to be available in #geeklog.  Of
> couse, email discourse is always welcome as well.
>
> -Vinny
> Who is already having fun...
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From tony at tonybibbs.com  Fri Oct 31 17:06:12 2003
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 31 Oct 2003 16:06:12 -0600
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far
 and how it relates to the API
In-Reply-To: <3FA2BB66.6040505@abtech.org>
References: <3FA04559.5080004@tonybibbs.com> <3FA2BB66.6040505@abtech.org>
Message-ID: <3FA2DCD4.6070207@tonybibbs.com>

I need more time to digest this but one quick note about your approach 
to event handling.  If I read it right, your method requires trip(s) to 
the database to be able to determine which modules wanted to be 
triggered when an event occurs.  I would like to see us implement this 
in a way that would avoid that overhead and I think we can do it.  For 
example, a module will know when it is shipped which modules it will try 
to interact with.  Here is a snippet that I think can handle this:

/**
* This calls an event on any module
*
* NOTE: this is just a stub in the API
*
* @param string $eventName Name of the event that was fired
* @param string $module Name of the module that triggered an event
* @param array $args Array of arguments for the handler
*
*/
function handleEvent($eventName, $module, $args)
{
}

For example purposes let's assume the following is the API 
implementation of the function above for the forum module:

/**
* Proxies events to the appropriate non-API event handlers
*
*
* @param string $eventName Name of the event that was fired
* @param string $module Name of the module that triggered an event
* @param array $args Array of arguments for the handler
*
*/
function handleEvent($eventName, $module, $args)
{
     switch ($module) {
         'Geeklog':
             // Call local non-API method to handle Messaging event
             return handleGeeklogEvent($eventName);
         'Messaging':
             // Call local non-API method to handle Messaging event
             return handleMessagingEvent($eventName);
         'Stories':
             // Call local non-API method to handle Story event
             return handleStoryEvent($eventName);
         default:
	    // For all other modules we don't care so bail
             return false;
     }
}

Though you can see the trend, here is what you would have in one of the 
event handlers.  Let's assume this is the forum's event handler for 
messaging:

function handleMessagingEvent($eventName)
{
     switch ($eventName) {
         'onPMSent':
             return ForumEventHandler::hand
     EventHandler::
}

In this way you don't need to register events in a database.  You may be 
able to condense this a bit by using is_callable() or method_exists() to 
avoid too many levels of event handling proxies but this demonstrates my 
idea.  Again, I think we should trim GL2 down to essential DB calls and 
if we can avoid them here I'd like to.  I'm sure there may be arguments 
for doing it in the DB which is fine, just let me know what they are 
(i.e. I'm not married to any decision yet).

Thoughts or concerns?

--Tony

Vincent Furia wrote:
> A couple comments I wanted to add about plugins and other GL2 stuff.  
> First, I think that we should consider making some of the 'core' 
> functionality into plugins instead. Specifically I'm referring to the 
> comment engine, the (potential) ratings engine, and the messaging system 
> (maybe even the logging system?).  This would allow users to replace the 
> functionality provided by these plugins.  A good example of this might 
> be replacing a standard comment system with a forum-like comment 
> system.  I think doing so would give GL2 even more flexibility.
> 
> I know Tony didn't mean the core feautre list to be exhaustive, but one 
> item I didn't see (but would like to see) was a configuration utility.  
> I think, with GL2, we should get away from forcing GL administrators 
> from editing config.php by hand and move to a fully web based 
> configuration utility that can be used by the plugins as well being used 
> for core feautres.
> 
> On that subject I think it's time to start putting together a document 
> that shows what core functionality GL2 will provide and any information 
> we have on how it will provide that.  Something like a design document.  
> It's something that I'd be willing to work on, but I'd need a lot of 
> information and support, especially from Tony.  Maybe this is something 
> that would best be done in a Wiki format?
> 
> Finally, I have a few comments about event handling system and a few 
> comments on plugins in general.  If we do this well, and efficiently, we 
> could have a really flexible, extensible system that will beat out every 
> other open source system I've seen.  For that reason I think its 
> important to focus, briefly on how the plugin event calls might work in 
> GL2.  This is just a rough idea, and I'd really like to see input on 
> what you all think of this.
> 
> Each plugin should be able to register the fact it wants to be called 
> when certain events occur:
>    registerEventCallback(plugin registering callback, plugin raising 
> event, event)
> 
> Then, a plugin can notify GL2 that event has occurred with:
>    raiseEvent(plugin raising event, event, parameters)   // parameters: 
> array of values
> 
> Upon being notified that an event occurred, GL2 can call the plugin API 
> for all plugins registered to recieve the event:
>    onEvent(plugin raising event, event, parameters)
> 
> Also plugins need to be able to invoke an event/function in another plugin:
>    invokeEvent(plugin providing function, event, parameters)
> 
> I'm still thinking about possible ways raiseEvent and invokeEvent can 
> handle returned values. One possibility, at least for invokeEvent, is 
> the functions could be required to return a small object containing 
> status (-1, failure; 0, plugin function not found; 1, success; etc.) and 
> the results of the call:
>    $P = invokeEvent(plugin, event, parameters);
>     if ($P->status > 0) {
>         echo $P->result;
>     }
> 
> Of course all this leads to a question if we should have a severely 
> simplified API where even core functionality such as the moderation 
> fuctions, comment functions, etc should all be called through this event 
> API (with a plugin name = 'core').  One advantage to doing it this way 
> would allow us to extend plugin functionality in later releases without 
> affecting the plugin API (which would prevent plugin obsolesence to an 
> extent).
> 
> Another issue I think we should start talking about is plugin 
> dependency, and how to handle it gracefully.  Obviously plugins will 
> support, to one extent or another, the use of other plugins.  This could 
> run the gambit from a plugin being dependent on another plugin to work, 
> to a plugin using another plugin in a non dependent way (i.e. the plugin 
> isn't required for operation, just for extended functionality).
> 
> I think that is more than enough to digest in one sitting.  If anyone 
> would like to chat with me I'll try to be available in #geeklog.  Of 
> couse, email discourse is always welcome as well.
> 
> -Vinny
> Who is already having fun...
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel

-- 
+----------------------------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|tony at tonybibbs.com |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  |
+----------------------------------------------------------------------+