Using Yahoo! Pipes with WEB-Services

I recently struggled a bit with Yahoo! Pipes when playing with this great tool trying to form a properly updating RSS feed from a WEB-Service source. The WEB-Service in question is available through one of Ohloh's API : Project.

The issue was related to the <guid> field required by (most?) RSS Aggregators (I use the excellent GoogleReader): fetching a data feed from a WEB-Service API usually means that no "proper" feed is in place and an RSS item must be created on-the-fly. This is no problem as such but when the RSS aggregator comes fetching updates, the <guid> field isn't updated dynamically by Yahoo! Pipes.

Part of the solution comes from using a mostly undocumented feature of Pipes: the y:id.value item tag.

After fetching the data from the data source, copy a field that can serve as good <guid> into the y:id.value field. In the example above, I used the updated_at field which, of course, isn't a <guid> per-se by not being global ; I'll find a better way next time around.


Finally, before connecting the "pipe output", insert the y:id.value in the pipes results as shown above.

For the interested, here is the pipe's address: Ohloh Project Summary as well as a link to all my pipes.

Have fun with Pipes... I know I do!

Design Pattern in PHP: Borg pattern

I thought about sharing some design patterns (expressed in PHP) I have documented. The first one is the borg. This design pattern serves as a good alternative option to the well-known singleton pattern.

The advantages of the borg are:

1. no need in client classes for special creation / access methods
2. easily sub-classed
3. more easily testable
   

Project
The project is located at GoogleCode.

Communication Types

There are 3 basic type of communication as illustrated in the following diagram:



Message
A message consists in a sequence of symbols, purposely chosen, from a lexicon. Note that the time-domain is not part of the information conveyed.

Open Sequence
An open sequence of messages carries information through the messages themselves but also through the order of the sequence i.e. the order in which the messages must be interpretated matters.

Timed Sequence
In a timed sequence, the time-domain adds information to the communication. Each symbol occupies, purposely, a temporal position in the ordered sequence. The receiving-end of the communication expects this timing to be respected in order to interpret the communication.

Network Functional Planes

Communication networks are usually modeled the following way:




User Plane
This plane supports the transport function i.e. the forwarding of traffic-units to end-point(s). The User-plane provides transport for the Control and Management planes.

Control Plane
This plane supports the control of the User-Plane with regards to the following aspects:

• Topology  ( virtual )
  
• Resources ( access etc.)

Of course the control-plane manages the virtual topology of networks unless one includes also "commands to humans to go dig-up streets and change patch-cords" i.e. humans are the only ones who control the fundamental physical topology (e.g. where cables are laid etc.).

Management Plane
This plane supports the management of the User and Control planes. The management functionality includes (see also FCAPS):

• Fault
• Configuration
• Accounting
• Provisioning
• Security

Network Protocol Stack Overview

The following diagram serves as reference.  One communication path is illustrated between the end-point E1 and E2. The communication traffic enters intermediate system A, is physically transmitted over to System B.

Interface "P"

This interface handles the "peer-to-peer" relationship between systems. In a communication system, the high-level semantic for this interface follows:

forward( traffic unit )

Where traffic unit (TU) represents the unit to forward to the end-point(s). On a packet network layer, the usual traffic unit is the packet (of course :-) whilst on an optical network layer the traffic unit will be an octet.

Interface "C"

This interface handles the "client-server" relationship between network protocol layers in a system. In a communication system, the high-level semantic for this interface follows:

forward( traffic unit, destination address, QOS )

The parameter destination address can either be explicit or implicit: this depends on the network layer in question. The parameter QOS (Quality Of Service) too can either be explicit or implicit depending the network layer technology.

Peer-To-Peer relationship

 The peer-to-peer relationship exists between separate (distinct) instantiations belonging to the same network protocol layer e.g. protocol sub-system N of system A and protocol sub-system N of system B. Physical proximity between sub-systems does not change the role of this interface.

Systems exchanging traffic through peer-to-peer relationships do so through a common address space. E.g. Internet Protocol. 

Client-Server relationship

The client-server relationship exists between a pair of network protocol layers. This relationship is characterize by a fundamental premise: the server-side of the relationship does not expose client-specific state i.e. the server must be designed to be "client-agnostic".

The client-side "adapts" the traffic it must send by mapping the desired destination address to the address space semantics of the server-side. The same logic is applied to the QOS parameter.