Infobus Socket Interface

Infobus Socket is a gateway to the Stanford Digital Library Infobus through sockets.

Table of Content

  1. Connecting to Infobus Socket
  2. Protocol of the Infobus Socket
    1. Example
    2. Definition
  3. Sample Client
  4. Known Bugs

Connecting to Infobus Socket

Establish a socket connection to the following address and port:

Machine: 171.64.75.99 (Mullet.Stanford.EDU)
Port: 30169

Warning:: all accesses, queries and responses of the Infobus through the Infobus-socket server are logged. If you object this policy, please don't use the server.

Access to the Infobus Socket interface is restricted to certain domains. If you need access please contact: crespo@cs.stanford.edu

Protocol of the Infobus Socket

The protocol used by the Infobus-socket server is a subset of the Infobus protocol.

Example

To give a feeling of how it works, let's walk through an example before defining formally the protocol. In the example, the lines precede with ">>>" are sent to the Infobus-socket server at Stanford; the lines precede with "<<<" are sent by the Infobus-socket server.

We are interested in querying Altavista about color printers. The result will contain the url and title of the web pages. The initial query will be:

>>> Altavista.RequestConstrain( 24, [None,"color printer",["url","title"],[]], [None, 10, []], "request1")

The constraint is requested over the Altavista object. The first parameter is an id (24) that will be used by the infobus in all responses to this specific request. The second parameter is the query specification; it's a list with 4 elements, the first is always None (which is the same as Null), the second one is the query, the third one is a list whose elements are the properties in which we are interested, and the last parameter is additional information for the query (normally is simply an empty list). The third parameter is the service preferences; it's a list with 3 elements, the first is always None the second one is the number of hits that will be returned by this request (10 in our case) and the the third one is a list with additional information for the service preferences (again, normally is simply an empty list). The last parameter is a "tag" that will be prepended to all responses related with this constrained collection

The response of the Infobus-socket will be:

<<< request1:SetTotalItem( 458 )
<<< request1:AddItem( 24, [["url","title"], ["http://xyz","first title"], ... 8 more lists of strings ..., ["http://abc","tenth title"]], ["cookie"])
<<< request1:CompletedRequest( 24 )

All responses are tagged with "request1". The first one is informing that the total number of items found in the query is 458.

The second one is returning the 10 first items found. This response has 2 parameters: the first one, is simply the message id specified in the RequestConstrain call, the second one is a list, whose first element is a list of the properties returned, the second elemente is a list of lists os strings with the items found, and the third element is a "cookie" that can be used for obtaining additional information from the constrained collection.

The last response is informing that all information regarding messageID 24 has been sent and that no more messages related with this ID will be sent in the future.

Let's suppose that we want the next 20 of the constrained collection defined above, we will send to the proxy:

>>> RequestItems( 25, ["url","title"], ["cookie"], 20, "request1" )

In the above call, we specify a new messageid, the properties in which we are interested, the cookie returned in the AddItem response, the number of items that should be returned and a tag.

The answer of the server will be:

<<< request1:AddItem( 25, [["url"],["title"]], ["http://xyz","11th title"], ... 18 more lists of string ... ["http://abc","30th title"]], ["cookie2"])
<<< request1:CompletedRequest( 25 )

Tip: You can use telnet to interact with the Infobus Socket Server and learn the protocol. Just type:
telnet machine_name port_number
where machine_name and port_number are the machine and port specified at the beginning of this document.

Formal Definition

General Rules:

All interaction have the form:
[<tag>:][<objectName>.]<methodName>(<parameters>)<NewLine>

where:

<tag>
A string of characters representing the optional tag of a response
<objectName>
A String of characters representing the object to which a command is directed. Usually this is the service name. If not present, then the action is targeted to the Infobus-socket server or it's a response generated by the Infobus-socket server.
<methodName>
A string of characters representing the action to be performed. Possible actions are listed below.
<parameters>
<item> | <parameters>,<item>
<item>
None | <int> | <string> | <list>
<string>
"<char>*" | '<char>*'
<list>
[] | [<listitems>]
<listitems>
<item> | <listitems>,<item>

Possible actions:

Possible responses:

Sample Client

A sample C++ client is provided.

Known Bugs

No bugs has been reported.

If you have found a bug, please send a report with as much information as possible about the conditions in which it happened to crespo@cs.stanford.edu


crespo@cs.stanford.edu