Hey guys,

While I am impressed with the amount of work and effort the 4 or 5 contributors have put into this project, it to me seems like a massive duplication of effort.

I understand entirely that its nice to have a single "go-to" for PHP code, where all code is consistent throughout all libraries, but this is exactly what PSR-0 and PSR-1 were developed for.

http://www.php-fig.org/

There is a substantial list of projects on there, including some of the largest in PHP.

All of those teams are moving towards using Consistent namespacing instead of using manual includes followed by weird invoke hacks or any of the following:

//Generic
new Eden_Session;
new Eden_Session();
Eden_Session::i();  

//Used outside of a class
eden('session');            
eden()->Session();       // alias
eden()->Eden_Session();

//Used in a class extended with Eden
$this->Session();        // alias
$this->Eden_Session();   
$this('session');       //PHP 5.3

/* Passing construct arguments */

//Generic
new Eden_Validation('something');
Eden_Validation::i('something');        //instantiate in a class

//Used outside of a class
eden('validation', 'something');        
eden()->Validation('something');     // alias
eden()->Eden_Validation('something');    

//Used in a class extended with Eden
$this->Validation('something');          // alias
$this->Eden_Validation('something'); 
$this('validation', 'something');       // PHP 5.3

This is a really weird collection of approaches to doing the exact same thing. Why is it being done this way?

new \Eden\Validation('something');

Tada, PSR-0 compatibility.

Furthermore, it is a massive shame that you guys are distributing this as one solid package. It would be substantially more useful to distribute this with Composer, meaning that instead of having to copy and paste specific files, then check for new versions later, and copy and paste the updated files every now and then... you could just run $ composer update and have any new changes pulled down.

You guys are doing a good job building an impressive library of components, but please don't ignore tools and conventions that have been made available with the express purpose of helping projects like this one.

I would be very interested in seeing you accept PSR-0 for the next version, with the view of moving to PSR-1 (at least) in the future. If anyone reading this agrees then please +1.

Adding basic Google Latitude history implementation.. I intend to flesh it out with the other Latitude functionality, especially if there was a demand.

(Sorry, this is my first time trying to contribute using GitHub.. Am I doin' it right?)

Had a problem when i moved mails, because the uid becomes an array in move, and is then a parameter for remove, which tests for int or string,

Signed-off-by: Guenter Weber [email protected]

page: http://eden.openovate.com/documentation/mailing/imap Next let's set the INBOX as the active mailbox. Figure 3 shows how we would set and retrieve the active mailbox in one line.

Figure 3. Set Active Mailbox FIRST! echo $imap->setMailboxes('INBOX')->getActiveInbox(); //--> INBOX ^^ this errors out, as method doesn't exist.. Instead it should read: echo $imap->setActiveMailbox("INBOX")->getActiveMailbox() -- both of the methods were named wrong...

http://www.eden-php.com/documentation/database/mysql/manipulation

Figure 4. Data Manilpulation

Has to be Figure 4. Data Manipulation

one "l" should be removed :-)