[geeklog-devtalk] geeklog-devel digest, Vol 1 #215 - 7 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Quick overview of GL2 and what we have so far and how it relates
       to the API (Tony Bibbs)
   2. Re: Anti Spam Features (Blaine Lang)
   3. Re: Quick overview of GL2 and what we have so far and how it relates to the API (Blaine Lang)
   4. New Plugin Wish (Tom Willett)
   5. Re: New Plugin Wish (Tony Bibbs)
   6. Re: New Plugin Wish (Tom Willett)

--__--__--

Message: 1
Date: Wed, 29 Oct 2003 16:55:21 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: Geeklog Development <geeklog-devel at lists.geeklog.net>
Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates
 to the API
Reply-To: geeklog-devel at lists.geeklog.net

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                  |

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


--__--__--

Message: 2
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Anti Spam Features
Date: Wed, 29 Oct 2003 19:38:03 -0500
Reply-To: geeklog-devel at lists.geeklog.net

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



--__--__--

Message: 3
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API
Date: Wed, 29 Oct 2003 19:38:45 -0500
Reply-To: geeklog-devel at lists.geeklog.net

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



--__--__--

Message: 4
From: "Tom Willett" <tomw at pigstye.net>
To: "Geeklog Core List" <geeklog-devel at lists.geeklog.net>
Date: Thu, 30 Oct 2003 13:41:26 +0000
Subject: [geeklog-devel] New Plugin Wish
Reply-To: geeklog-devel at lists.geeklog.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


--__--__--

Message: 5
Date: Thu, 30 Oct 2003 08:27:57 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] New Plugin Wish
Reply-To: geeklog-devel at lists.geeklog.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

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                  |

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


--__--__--

Message: 6
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] New Plugin Wish
Date: Thu, 30 Oct 2003 17:02:41 +0000
Reply-To: geeklog-devel at lists.geeklog.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


--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest