ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent-MP/MP.pm
(Generate patch)

Comparing AnyEvent-MP/MP.pm (file contents):
Revision 1.45 by root, Thu Aug 13 01:16:24 2009 UTC vs.
Revision 1.46 by root, Thu Aug 13 01:46:10 2009 UTC

855This also saves round-trips and avoids sending messages to the wrong port 855This also saves round-trips and avoids sending messages to the wrong port
856(hard to do in Erlang). 856(hard to do in Erlang).
857 857
858=back 858=back
859 859
860=head1 RATIONALE
861
862=over 4
863
864=item Why strings for ports and noderefs, why not objects?
865
866We considered "objects", but found that the actual number of methods
867thatc an be called are very low. Since port IDs and noderefs travel over
868the network frequently, the serialising/deserialising would add lots of
869overhead, as well as having to keep a proxy object.
870
871Strings can easily be printed, easily serialised etc. and need no special
872procedures to be "valid".
873
874=item Why favour JSON, why not real serialising format such as Storable?
875
876In fact, any AnyEvent::MP node will happily accept Storable as framing
877format, but currently there is no way to make a node use Storable by
878default.
879
880The default framing protocol is JSON because a) JSON::XS is many times
881faster for small messages and b) most importantly, after years of
882experience we found that object serialisation is causing more problems
883than it gains: Just like function calls, objects simply do not travel
884easily over the network, mostly because they will always be a copy, so you
885always have to re-think your design.
886
887Keeping your messages simple, concentrating on data structures rather than
888objects, will keep your messages clean, tidy and efficient.
889
890=back
891
860=head1 SEE ALSO 892=head1 SEE ALSO
861 893
862L<AnyEvent>. 894L<AnyEvent>.
863 895
864=head1 AUTHOR 896=head1 AUTHOR

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines