To help get things started here, I'm going to lay out a few bits of information (and links to more) about CAN bus, and specifically the aspects of it that will be of interest to people working with Macchina.
First, some info that might serve as clarification. CAN is a protocol that can run on many different physical configurations, and is relatively flexible in its applications. With the exception of implementations that use the SAE J2411 "Single-Wire CAN" ("SWC") standard found mainly in recent GM vehicles and known as GMLAN, the physical layer of most CAN implementations you'll likely encounter involve 4 signals: CAN-Low and CAN-High composing a balanced differential signal, Ground, and Power. Many implementations employ terminating resistors between CAN-High and CAN-Low at each "end" of the bus. Depending on your system, you may need to install a resistor between the two data signals on your CAN controller.
Aside from the physical wiring, Macchina takes care of much of the physical and transfer layers of the protocol, leaving us with the more immediately useful Object and Application layers, and the messages being passed around on the bus.
Those messages (or "frames") are sent and received by the CAN controller, and carry all the data being shuttled around the bus. Wikipedia's description of these frames ( http://en.wikipedia.org/wiki/CAN_bus#Frames ) is surprisingly helpful, and when coupled with some hardware documentation describing a specific set of messages, can get you a very long way toward decoding and controlling CAN-aware equipment. The "Identifier" section--either 11 bits in the case of CAN 2.0 A, or 29 bits, split into two sections, in the case of CAN 2.0 B--of these message frames is just about what it sounds like: a unique identifier for the particular message type. In a data frame, the identifier, along with a few other configuration and descriptive bits, accompanies up to 8 bytes of data. Hardware documentation will hopefully tell what the identifiers are for the messages the equipment sends and receives, but if documentation is scarce, it's sometimes necessary to just listen in on the bus and take a look at what messages and identifiers are present.
Again, this post will hopefully get you thinking in the right sort of direction and on the right sort of layer for working with CAN messages, and relying on the CAN controller and transceiver to handle all the tricky timing and such. Message Identifiers and, effectively, addresses, are tricky enough to manage without having to worry about balanced signals and bus arbitration.
This post will hopefully also serve as a jumping-off point for discussion and knowledge sharing as you begin sniffing and poking at whatever might be living on your buses, so comment away, and happy CANning!