| … | |
… | |
| 155 | |
155 | |
| 156 | use AE (); |
156 | use AE (); |
| 157 | |
157 | |
| 158 | use base "Exporter"; |
158 | use base "Exporter"; |
| 159 | |
159 | |
| 160 | our $VERSION = 1.26; |
160 | our $VERSION = 1.27; |
| 161 | |
161 | |
| 162 | our @EXPORT = qw( |
162 | our @EXPORT = qw( |
| 163 | NODE $NODE *SELF node_of after |
163 | NODE $NODE *SELF node_of after |
| 164 | configure |
164 | configure |
| 165 | snd rcv mon mon_guard kil psub peval spawn cal |
165 | snd rcv mon mon_guard kil psub peval spawn cal |
| … | |
… | |
| 952 | overhead, as well as having to keep a proxy object everywhere. |
952 | overhead, as well as having to keep a proxy object everywhere. |
| 953 | |
953 | |
| 954 | Strings can easily be printed, easily serialised etc. and need no special |
954 | Strings can easily be printed, easily serialised etc. and need no special |
| 955 | procedures to be "valid". |
955 | procedures to be "valid". |
| 956 | |
956 | |
| 957 | And as a result, a miniport consists of a single closure stored in a |
957 | And as a result, a port with just a default receiver consists of a single |
| 958 | global hash - it can't become much cheaper. |
958 | closure stored in a global hash - it can't become much cheaper. |
| 959 | |
959 | |
| 960 | =item Why favour JSON, why not a real serialising format such as Storable? |
960 | =item Why favour JSON, why not a real serialising format such as Storable? |
| 961 | |
961 | |
| 962 | In fact, any AnyEvent::MP node will happily accept Storable as framing |
962 | In fact, any AnyEvent::MP node will happily accept Storable as framing |
| 963 | format, but currently there is no way to make a node use Storable by |
963 | format, but currently there is no way to make a node use Storable by |
