docs include 'apply'

docs/source/parallelz/parallel_intro.txt

@@ -175,13 +175,16 b' everything is working correctly, try the following commands:'
 	Out[5]: {0: 'Hello, World', 1: 'Hello, World', 2: 'Hello, World', 3: 
 	        'Hello, World'}
 
-Remember, a client needs to be able to see the Controller.  So if the controller is on a different machine, and you have ssh access to that machine, then you would connect to it with::
+Remember, a client needs to be able to see the Controller. So if the
+controller is on a different machine, and you have ssh access to that machine,
+then you would connect to it with::
 
 .. sourcecode:: ipython
 
     In [2]: c = client.Client(sshserver='mycontroller.example.com')
 
-Where 'mycontroller.example.com' is the url or IP address of the machine on which the Controller is running.
+Where 'mycontroller.example.com' is the url or IP address of the machine on
+which the Controller is running.
 
 You are now ready to learn more about the :ref:`MUX
 <parallelmultiengine>` and :ref:`Task <paralleltask>` interfaces to the

docs/source/parallelz/parallel_multiengine.txt

@@ -71,7 +71,8 b' Parallel map'
 
 Python's builtin :func:`map` functions allows a function to be applied to a
 sequence element-by-element. This type of code is typically trivial to
-parallelize. In fact, since IPython's interface is all about functions anyway, you can just use the builtin :func:`map`, or a client's :map: method:
+parallelize. In fact, since IPython's interface is all about functions anyway,
+you can just use the builtin :func:`map`, or a client's :map: method:
 
 .. sourcecode:: ipython
 
@@ -124,6 +125,48 b' done in blocking or non-blocking mode (non-blocking is default) using the'
 :meth:`execute` method, and calling functions can be done via the
 :meth:`.View.apply` method.
 
+apply
+-----
+
+The main method for doing remote execution (in fact, all methods that
+communicate with the engines are built on top of it), is :meth:`Client.apply`.
+Ideally, :meth:`apply` would have the signature :meth:`apply(f,*args,**kwargs)`,
+which would call f(*args,**kwargs) remotely.  However, since :class:`Clients`
+require some more options, they cannot reasonably provide this interface.
+Instead, they provide the signature::
+
+    c.apply(f, args=None, kwargs=None, bound=True, block=None,
+                    targets=None, after=None, follow=None)
+
+In order to provide the nicer interface, we have :class:`View` classes, which wrap
+:meth:`Client.apply` by using attributes and extra :meth:`apply_x` methods to determine
+the extra arguments. For instance, performing index-access on a client creates a
+:class:`.LoadBalancedView`.
+
+.. sourcecode:: ipython
+
+    In [4]: view = rc[1:3]
+    Out[4]: <DirectView [1, 2]>
+
+    In [5]: view.apply<tab>
+    view.apply  view.apply_async  view.apply_async_bound  view.apply_bound  view.apply_sync  view.apply_sync_bound
+
+A :class:`DirectView` always uses its `targets` attribute, and it will use its `bound`
+and `block` attributes in its :meth:`apply` method, but the suffixed :meth:`apply_x`
+methods allow specifying `bound` and `block` via the different methods.
+
+==================  ==========  ==========
+method              block       bound
+==================  ==========  ==========
+apply               self.block  self.bound
+apply_sync          True        False
+apply_async         False       False
+apply_sync_bound    True        True
+apply_async_bound   False       True
+==================  ==========  ==========
+
+For explanation of these values, read on.
+
 Blocking execution
 ------------------
 
@@ -154,7 +197,7 b' by index-access to the client:'
 
     In [7]: rc.execute('c=a-b',targets=[1,3])
 
-    In [8]: rc[:]['c']
+    In [8]: rc[:]['c'] # shorthand for rc.pull('c',targets='all')
     Out[8]: {0: 15, 1: -5, 2: 15, 3: -5}
 
 .. note::