[PEPr] Comment on Web Services::SabreAMF
| From: | Philippe Jausions | Date: | Fri, 05 May 2006 00:00:23 +0000 |
| Subject: | [PEPr] Comment on Web Services::SabreAMF | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-42449@lists.php.net to get a copy of this message | ||
Philippe Jausions (http://pear.php.net/user/jausions) has commented on the proposal for Web
Services::SabreAMF.
Comment:
No it doesn't :-) I think a lot of commenting should be done... (no
offense.)
1. I'm not too familiar with AMF, so I'm not sure which category this
would go in. The name would need to change unless, SabreAMF is a standard
on its own. If it's just branding of AMF implementation then Services_AMF
or Net_AMF may be better.
2. From what I understand a good deal of all this is serialization /
unserialization of data and mapping AMF types to PHP types.... Sounds much
like the whole discussion of where the JSON package should go.
3. Why put a single class with just constants in it? Either make them
global constants, or have them part of another class.
4. I don't remember how the interface names should be declared. That topic
kind of died off a while back.
5. Code is indented one too many time, it should be flush with the left
hand-side margin.
6. Are DT_ and ET_ prefixes standardized in the AMF specification?
Otherwise, what do they mean.
7. Some PEAR CS such as:
+ "foreach($data as $k=>$v)" instead of "foreach ($data as $k => $v)"
+ "function name(...) {" the opening curly braces should go on the
following line.
+ one-liner if's without "{}" should be multilines with block {}
8. You shouldn't use require_once dirname(__FILE__) '../Const.php';
inclusions but require_once 'Services/AMF/Const.php'; instead.
9. What is the purpose of the SabreAMF_AMF3_Wrapper class?
10. Use HTTP_Request instead of cURL extension. It makes the package more
portable (hopefully, cURL will be supported by HTTP_Request in the
future.)
11. You should use PEAR_Exception instead of simply Exception. Also create
sub-classes for each different exception. Read the Exception RFC
(http://pear.php.net/pepr/pepr-proposal-show.php?id=132) and/or PEAR
manual about this.
12. Docblock headers should really describe the methods/properties instead
of just repeating the name.
13. For the server-side, I'd really like to see an implementation similar
to Services_WebService and/or XML_RPC2. The best would be to try to
incorporate or make AMF a compatible backend to them.
Otherwise, it seems this package could be a very useful and a nice
addition to PEAR.
-Philippe
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=348
--
Sent by PEPr, the automatic proposal system at http://pear.php.net