[PEPr] Changes in proposal for Networking::Net_SMPP
| From: | Ian Eure | Date: | Mon, 25 Apr 2005 19:35:22 +0000 |
| Subject: | [PEPr] Changes in proposal for Networking::Net_SMPP | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-37405@lists.php.net to get a copy of this message | ||
Ian Eure (http://pear.php.net/user/ieure) has edited the proposal for Networking::Net_SMPP.
Change comment:
- Upload new package version.
- Update file locations.
- Update description to better reflect the intent of this package, and
link to the Net_SMPP_Client proposal.
This version should address most of the negative comments received so far.
Globals are replaced with static vars in class methods. The vendor
extensions are heavily reworked to reflect this, and vendor extensions are
stored in vendor classes, instead of being largely procedural.
The only remaining issue has to do with vendor extensions. When a vendor
is loaded, it sets a static var and alters the command list, status
descriptions, and optional parameters. This could potentially be an issue
if you want to send SMPP through multiple vendors in a single script run.
I don't think it's a huge deal, since:
a- So far as I know, this is not a common practice.
b- Vendor extensions should be a superset of the existing SMPP
functionality, and there should be no difference unless the actual
extensions are used. E.g. the data generated from a plain submit_sm is
identical to that generated from a mBlox submit_sm so long as the mBlox
extensions aren't used. Additionally, SMPP systems should ignore optional
parameters they don't understand, so it would likely work even if there
was a difference, or a vendor-specific parameter was set on accident.
Comments on this scenario are welcome.
Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=239
--
Sent by PEPr, the automatic proposal system at http://pear.php.net