"Log shipping" is the second implementation. It is a sort of an end-around the original software design. Effectively, the slon program "archives" anything done on the node into SQL files ("logs"). These logs are not the same as the Postgres Write-Ahead-Logs (WALs). These logs are text-based SQL commands, and only handle inserts, updates and deletes. Slony-1 logs don't handle, for example, database structural changes, user password changes, create table/drop table commands, new namespaces (schemas), et cetera. Those structural changes must be applied specially using the slonik and SQL languages. To create a log-shipping Postgres instance, one must have at least two nodes running Slony-1 in a "classic" architecture. The output from that will be the logs to be shipped.
One of the benefits of log shipping is that it requires no external systems to have database superuser privileges. It also allows the destination database to pick up logs as desired, instead of constantly receiving updates. The administrator of the slons can decide how frequently logs are created, as well. Network connections between remote sites are no longer time-critical.