--- AnyEvent-MP/MP.pm	2009/08/31 11:11:27	1.74
+++ AnyEvent-MP/MP.pm	2009/09/03 20:16:36	1.78
@@ -6,16 +6,15 @@
 
    use AnyEvent::MP;
 
-   $NODE      # contains this node's noderef
-   NODE       # returns this node's noderef
-   NODE $port # returns the noderef of the port
+   $NODE      # contains this node's node ID
+   NODE       # returns this node's node ID
 
    $SELF      # receiving/own port id in rcv callbacks
 
    # initialise the node so it can send/receive messages
    configure;
 
-   # ports are message endpoints
+   # ports are message destinations
 
    # sending messages
    snd $port, type => data...;
@@ -42,7 +41,7 @@
 
    bin/aemp                - stable.
    AnyEvent::MP            - stable API, should work.
-   AnyEvent::MP::Intro     - uptodate, but incomplete.
+   AnyEvent::MP::Intro     - explains most concepts.
    AnyEvent::MP::Kernel    - mostly stable.
    AnyEvent::MP::Global    - stable API, protocol not yet final.
 
@@ -58,8 +57,6 @@
 For an introduction to this module family, see the L<AnyEvent::MP::Intro>
 manual page and the examples under F<eg/>.
 
-At the moment, this module family is a bit underdocumented.
-
 =head1 CONCEPTS
 
 =over 4
@@ -163,6 +160,8 @@
 
 Extracts and returns the node ID from a port ID or a node ID.
 
+=item configure $profile, key => value...
+
 =item configure key => value...
 
 Before a node can talk to other nodes on the network (i.e. enter
@@ -179,12 +178,12 @@
 
 The function first looks up a profile in the aemp configuration (see the
 L<aemp> commandline utility). The profile name can be specified via the
-named C<profile> parameter. If it is missing, then the nodename (F<uname
--n>) will be used as profile name.
+named C<profile> parameter or can simply be the first parameter). If it is
+missing, then the nodename (F<uname -n>) will be used as profile name.
 
 The profile data is then gathered as follows:
 
-First, all remaining key => value pairs (all of which are conviniently
+First, all remaining key => value pairs (all of which are conveniently
 undocumented at the moment) will be interpreted as configuration
 data. Then they will be overwritten by any values specified in the global
 default configuration (see the F<aemp> utility), then the chain of
@@ -374,9 +373,9 @@
 
 sub rcv($@) {
    my $port = shift;
-   my ($noderef, $portid) = split /#/, $port, 2;
+   my ($nodeid, $portid) = split /#/, $port, 2;
 
-   $NODE{$noderef} == $NODE{""}
+   $NODE{$nodeid} == $NODE{""}
       or Carp::croak "$port: rcv can only be called on local ports, caught";
 
    while (@_) {
@@ -494,7 +493,7 @@
 C<eval> if unsure.
 
 In the second form (another port given), the other port (C<$rcvport>)
-will be C<kil>'ed with C<@reason>, iff a @reason was specified, i.e. on
+will be C<kil>'ed with C<@reason>, if a @reason was specified, i.e. on
 "normal" kils nothing happens, while under all other conditions, the other
 port is killed with the same reason.
 
@@ -507,7 +506,7 @@
 As a rule of thumb, monitoring requests should always monitor a port from
 a local port (or callback). The reason is that kill messages might get
 lost, just like any other message. Another less obvious reason is that
-even monitoring requests can get lost (for exmaple, when the connection
+even monitoring requests can get lost (for example, when the connection
 to the other node goes down permanently). When monitoring a port locally
 these problems do not exist.
 
@@ -526,9 +525,9 @@
 =cut
 
 sub mon {
-   my ($noderef, $port) = split /#/, shift, 2;
+   my ($nodeid, $port) = split /#/, shift, 2;
 
-   my $node = $NODE{$noderef} || add_node $noderef;
+   my $node = $NODE{$nodeid} || add_node $nodeid;
 
    my $cb = @_ ? shift : $SELF || Carp::croak 'mon: called with one argument only, but $SELF not set,';
 
@@ -652,16 +651,16 @@
 }
 
 sub spawn(@) {
-   my ($noderef, undef) = split /#/, shift, 2;
+   my ($nodeid, undef) = split /#/, shift, 2;
 
    my $id = "$RUNIQ." . $ID++;
 
    $_[0] =~ /::/
       or Carp::croak "spawn init function must be a fully-qualified name, caught";
 
-   snd_to_func $noderef, "AnyEvent::MP::_spawn" => $id, @_;
+   snd_to_func $nodeid, "AnyEvent::MP::_spawn" => $id, @_;
 
-   "$noderef#$id"
+   "$nodeid#$id"
 }
 
 =item after $timeout, @msg
@@ -710,7 +709,7 @@
 
 Erlang relies on special naming and DNS to work everywhere in the same
 way. AEMP relies on each node somehow knowing its own address(es) (e.g. by
-configuraiton or DNS), but will otherwise discover other odes itself.
+configuration or DNS), but will otherwise discover other odes itself.
 
 =item * Erlang has a "remote ports are like local ports" philosophy, AEMP
 uses "local ports are like remote ports".
@@ -733,7 +732,7 @@
 needs a queue. AEMP is event based, queuing messages would serve no
 useful purpose. For the same reason the pattern-matching abilities of
 AnyEvent::MP are more limited, as there is little need to be able to
-filter messages without dequeing them.
+filter messages without dequeuing them.
 
 (But see L<Coro::MP> for a more Erlang-like process model on top of AEMP).