1. FF 12 : Clients A presentation by Robin Upton (2009-10-16) ‏ Latest version at www.altruists.org/ff12 Attribution – NonCommercial - ShareAlike www.altruists.org V1.0.0 http://www.altruists.org/ff11 Recommended Pre-requisite: FF11: Hooks

2. What is an F2F Client? An F2F client is a piece of software designed as an interface for an F2F server. This presentation details the default F2F client (coded in JS), to help developers of the other clients maintain compatibility. HTTP(S)‏ If they communicate over the internet, HTTPS should be used. F2F Server F2F Server F2F Client F2F Client

3. F2F Server F2F Server Communication Clients are connected to only one server at a time. The client uses AJAX to exchange the XML messages detailed in /FF8. Messages in either direction are wrapped in a : http://www.altruists.org/ff8...

4. DOM Sections F2F Clients keep data in separate sections: The client has 4 other, less important, sections: clipboard, drag-drop, event-log, traffic-log Clientsid e Serversid e semantic (XML)‏ display (XHTML)‏ Calculation Data (Invisible)‏ User Interaction (Visible)‏ Other F2F Soft- Systems hooks/render` User input

5. F2F Processing Overview semantic (XML)‏display (XHTML)‏server (XML)‏ Sent to server XSLT, datastores & communications XSL by namespace XSL by namespace XSLT by namespace JS DOM manipulation JS DOM manipulation Sent to client no processing JS operations & XSL transforms no processing SVG images no processing Request: Clientside Serversid e replaced by chunk of XML

6. All requests send to the client are s. http://www.altruists.org/ff8 The JS client supports: thread-add, thread-edit, thread-delete Managing Windows: Miscellaneous: Since they are hardcoded, each client has a fixed set. alert, clipboard-clear, data-input, js-value-set, packet, param-set, receive, send (This list is not yet fixed)‏

7. Clients process an by requesting this resource by URI from their F2F soft-system: http://www.altruists.org/ff11 Client Soft- system uri src The server returns a Scalable Vector Graphic (SVG) image, which is scaled as requested and included in the displayDOM.

8. Clients process a by requesting this resource by URI from their F2F soft-system:...optional XML... Client Soft- system uri src The server returns an XSL stylesheet, which is applied to the item.

9. Clients process a by requesting a list of handlers for this resource from their F2F soft-system: The client picks (s) according to the namespace of the data...XML element(s) required... <ha <h<h Client Soft- system hook uri src handler-list Client Soft- system handler uri src XSL handler Handlers are XSL transforms, which are applied to the contained data.

10. Clients process a by requesting the corresponding XML script from their F2F soft-system: Client Soft-system uri src This XMLreplaces the. Some XML

11. Clients send a for processing at their F2F soft-system. http://www.altruists.org/ff11Client Soft- system... If marked this-return=“0”, the servicereq is then discarded, otherwise, it is kept as a placeholder for the returning data. (XML results)‏

12. Clientside processing When clients have sent a to their F2F soft-system......if marked this-return=“0”, the servicereq is discarded;...else if marked this-render=“suspend”, no rendering is carried out until a response is received;...else rendering continues as usual. http://friend2friend.net/modules/dev/data-validator... The render hook creates a visual display of the servicereq:

13. F2F Client Address Hierarchy F2F client addresses locate the soft system they are connected to: The particular service request is indicated by request: server = ”http://f2f.example.com” system = ”default” request = ”23” The thread attribute holds the security context and window id thread = ”4.1” The node attribute defines the DOM section {semantic,display}: node = ”semantic” The context differentiates them from the server (and one another): context= ”client-123”

14. Receiving Incoming Messages http://www.altruists.org/ff8 To motivate descriptive terms for messages, we use a metaphor:- Assume the highest point of a communication is always its source. Downstream messages arrive unsolicited: (type= “down”, “send”, “send2”)‏ Upstream messages are replies to earlier downstream messages: (type= “term”, “return”)‏ The s of a are processed separately, currently in order, though this policy may later be dropped.

15. Receiving Upstream Messages (Replies) ‏ Messages of type “term” or “return” are replies (upstream), and need node, thread & sreq attributes to specify the originating call. If these correspond to a waiting, the incoming data is added below (“return”) or used to replace (“term”) it, causing the affected thread to be re-rendered. Otherwise, the message is ignored. (Possibly a warning should be issued).

16. Receiving Downstream Messages Messages of type “down” are new requests from the server. Therefore, they need no thread, node or request attributes. These messages may only have children, which are processed in serial order by the client. Other content is ignored (probably with a warning).

17. Summary Recommended Follow-up: FF13: Modules http://www.altruists.org/ff13 F2F clients are graphical interfaces to F2F servers. F2F Server F2F Server F2F Client F2F Client The Semantic (XML) & Display (HTML) sections are separate. The client understands a range of request items. servicereq displayreq imagereq hookreq scriptreq clientreq