gmane.comp.php.pear.devel

http://pear.pdepend.org/ is not accesible

Michael Wang — 2013-05-24T00:35:28

Hi there,

I need some help on accessing http://pear.pdepend.org/ and http://pear.phpmd.org/ 

I have been trying to connect to them for a fews days, but always got the following error via command line on MacOSX 10.6.8


Updating channel "pear.pdepend.org"
Channel "pear.pdepend.org" is not responding over http://, failed with message: Connection to `pear.pdepend.org:80' failed: Connection refused
Trying channel "pear.pdepend.org" over https:// instead
Cannot retrieve channel.xml for channel "pear.pdepend.org" (Connection to `pear.pdepend.org:443' failed: Connection refused)

Updating channel "pear.phpmd.org"
Channel "pear.phpmd.org" is not responding over http://, failed with message: Connection to `pear.phpmd.org:80' failed: Connection refused
Trying channel "pear.phpmd.org" over https:// instead
Cannot retrieve channel.xml for channel "pear.phpmd.org" (Connection to `pear.phpmd.org:443' failed: Connection refused)

and the two links are not accessible through browser, either.


Michael Wang
Automated Testi

Re: subscribe me

Michael Gauthier — 2013-05-21T15:25:15

Kehinde,

You can subscribe at: http://pear.php.net/support/lists.php

Cheers,
Mike

subscribe me

kehinde lawal — 2013-05-20T21:25:15

kehinde lawal
08023909100

...hope spring eternal in the human soul...

Re: Move Net_MAC to GitHub

Daniel O'Connor — 2013-05-16T13:29:57

there. Enjoy

Re: [PEPr] Comment on Caching::phpfastcache

Lester Caine — 2013-05-14T05:44:59

While keeping compatibility with 5.1 may seem a good idea, I'd strongly suggest 
that you treat it like PHP4 and pretend it does not exist. One of the problems 
with clean new code is throwing in stuff which has no place going forward. 
Personally I wish they had simply called PHP5.3 '6' and had done with it. In 
reality it's that different in areas that it should be considered a major 
version. PHP5.1 is no longer supported, and should be treated as such.

Re: [PEPr] Comment on Caching::phpfastcache

Khoa Bui — 2013-05-13T22:03:41

thanks Mansion for some example on the comment.
I have created the list of what I need to improve already.

Yeah, I like to learn new thing too. PHP 5.3 is amazing on new things, but I want to make it compatible with PHP 5.1+ - It hard cause 5.1 is less magic function.
However, I will make a new version first, before I ask u guys for help on stuff.

Today is a day I learn many new things. Hehehehe. From your comment, I know MongoDB , and this is first time I see a NoSQL database, interesting.

Thanks Dude, I will not change my project status to Votes until I finish my next version.


________________________________
 From: Bertrand Mansion <bmansion< at >mamasam.com>
To: Khoa Bui <khoaofgod< at >yahoo.com> 
Cc: PEAR developer mailinglist <pear-dev< at >lists.php.net> 
Sent: Monday, May 13, 2013 2:56 PM
Subject: Re: [PEAR-DEV] [PEPr] Comment on Caching::phpfastcache
 


Le 13 mai 2013 à 23:12, Khoa Bui <khoaofgod< at >yahoo.com> a écrit :



Hi Khoa,

If you need help with design patterns, api and stuff, don't hesitate to ask

Re: [PEPr] Comment on Caching::phpfastcache

Bertrand Mansion — 2013-05-13T21:56:20

Le 13 mai 2013 à 23:12, Khoa Bui <khoaofgod< at >yahoo.com> a écrit :



Hi Khoa,

If you need help with design patterns, api and stuff, don't hesitate to ask on the list.
There is definitely a room for a good caching library in PHP that works with 5.3+ and modern backends.

Regards,

--
Bertrand Mansion
Mamasam

Re: [PEPr] Comment on Caching::phpfastcache

Michael Gauthier — 2013-05-13T20:12:55

Sounds great. I look forward to reviewing the new version.

Cheers,
Mike

[PEPr] Comment on Caching::phpfastcache

Khoa Bui — 2013-05-13T21:12:39

hi guys, I'm Khoa.



I agree with Bertrand Massion too, my code need improve design. 



I just created new plan for next version.



I just looked at other classes, and I see I have to learn more from them on
patterns design.



Right now, my code is work good, but it is painful to add a new backend or
modify an existing one.



Thanks for all advises,



I will propose my next version on couple months soon.

[PEPr] Comment on Caching::phpfastcache

Michael Gauthier — 2013-05-13T21:06:50

After looking at the code, I agree with Bertand. This class is doing too
much. For example, emailing error messages does not belong in a cache
library.



There is definitely room in PEAR for a cache library, but the code needs to
be split into multiple reusable classes rather than one monolithic static
class.



Serializing cache data is potentially a security issue as a vulnerability
in any backend now has the potential to execute code on the server.

[PEPr] Comment on Caching::phpfastcache

Bertrand Mansion — 2013-05-13T19:47:38

Hi,



I only looked quickly at the code.



I think that there is room for improvements. The 'one class does it all'
concept is bad here because it reduces your code reusability,
extendability, flexibility and creates maintenance problems. It makes it
painful to add a new backend (redis, apcu, tokyotyrant, mongodb, ...) or
modify an existing one.



You could improve it by looking at the current Cache_Lite or Cache
packages, and investigating design patterns like Bridge and maybe Chain of
responsability in case you want to keep the possibility to have multiple
backends.



http://en.wikipedia.org/wiki/Bridge_pattern

http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern



You could allow backends to register themselves as available upon loading.
You seem to have defined your own order of priority for backends, this
should maybe left as a parameter for the user.



You use static functions for set/get. This is also wrong because it doesn't
allow to have more than one cache. You should provide a facto

[PEPr] Proposal for PHP::phpfastcache

Khoa Bui — 2013-05-13T18:46:19

Khoa Bui (http://pear.php.net/user/khoaofgod) proposes PHP::phpfastcache.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=692

Move Net_MAC to GitHub

Andrew Teixeira — 2013-05-13T13:49:08

Hello,

Although I haven't updated it in years, I wanted to move a package I have
in PEAR (Net_MAC) to GitHub.  I used the scripts from
https://github.com/pear/pear-svn-git however I get to "2-to-github.sh" and
I receive the error:

ERROR: Permission to pear/Net_MAC.git denied to coreone.
fatal: The remote end hung up unexpectedly
ERROR: problem pushing Net_MAC to GitHub.

I'm assuming my GitHub username (coreone) needs some permissions on GitHub
to be able to push up to this repo.  Also, would these scripts migrate the
package to PEAR or PEAR2?  It would probably make sense for it to go in
PEAR2 unless the package needs some updating beforehand.

Thanks!

Re: Moving Net_URL2 to Github

Christian Weiske — 2013-04-20T20:10:20

Hello Michael,



I've moved it to git.

Re: [PEPr] +1 for Authentication::JWT

till — 2013-04-05T17:07:23

Should have looked closer:

Changing to conditional:

Class is missing namespace or proper PSR-0 name.

Till 

On Thursday, April 4, 2013 at 11:54 AM, Till Klampaeckel wrote:

[PEPr] +1 for Authentication::JWT

Bertrand Mansion — 2013-04-04T22:40:32

Bertrand Mansion (http://pear.php.net/user/mansion) has voted +1 on the proposal for Authentication::JWT.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=688
Vote information:
http://pear.php.net/pepr/pepr-vote-show.php?id=688&handle=mansion

[PEPr] +1 for Authentication::JWT

Christian Weiske — 2013-04-04T20:35:21

Christian Weiske (http://pear.php.net/user/cweiske) has voted +1 on the proposal for Authentication::JWT.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=688
Vote information:
http://pear.php.net/pepr/pepr-vote-show.php?id=688&handle=cweiske

This vote is conditional. The condition is:

- _handleJsonError misses < at >throws

- tests: testDecodeFromPython assert parameters are in the wrong order

- use exception codes so exceptions can be distinguished programmatically

- I'm not fully happy with the "all static methods" approach, even if it may be fine here. Smells a bit. Does it make sense to have an JWT object and pre-set the key, so that I can encode/decode multiple tokens?

- use static:: instead of JWT::

- the tests don't really test the encoding/decoding functionality except the python test. All others just work by $str = decode(encode($str)) - so I could replace the implementation with anything, and it would work

- why are all (except one) methods public?

- why is the one meth

[PEPr] +1 for Authentication::JWT

Till Klampaeckel — 2013-04-04T09:54:31

Till Klampaeckel (http://pear.php.net/user/till) has voted +1 on the proposal for Authentication::JWT.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=688
Vote information:
http://pear.php.net/pepr/pepr-vote-show.php?id=688&handle=till

Re: [PEAR] [ANNOUNCEMENT] PHP_CodeSniffer-1.5.0RC2 (beta) Released.

Harry Kapsales — 2013-04-04T01:23:28

[PEPr] Call for votes on Authentication::JWT

Anant Narayanan — 2013-04-04T00:30:48

Anant Narayanan (http://pear.php.net/user/anant) has initiated the call for votes on Authentication::JWT.

Please review the proposal and give your vote here:
http://pear.php.net/pepr/pepr-proposal-show.php?id=688

Re: Moving URI_Template to GitHub

Christian Weiske — 2013-04-03T05:29:44

Hello Martin,



You have access now. https://github.com/pear/URI_Template