Post on 30-Dec-2015
transcript
FF 1 : Modules
A presentation by Robin Upton (2009-08-03)Latest version at www.altruists.org/ff13
Attribution – NonCommercial - ShareAlikewww.altruists.org
V1.2.0
http://www.altruists.org/ff13
Recommended Pre-requisite: FF12: Clients
3
What is an F2F Module?
A module is a digitally signed, uniquely identified set of resources:
Modules are blueprints for soft-nodes, defining their behaviour,in the same way that XVMs are blueprints for soft-systems.
rdf:about http://friend2friend.net/modules/lib/ MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwt5pEliqkVR6ZV5umPoRpwmLlNfG6QEpKju7VM7aHlnJDn1/mS1Gg82+BXAXA9EhTNoLrg7Pi6X0X9q7iRS5hrBbR10ZNyBkAuxQdPgaQINMBo7PopDokaoIS4yQTJjm3x+x1SLqWBlMKNsS4od9eHMZLLpysziYQDQGUqFIi/wIDAQAB
pkey
Services Filters
Displays Images
Scripts Hooks
Datastores
ResourcesModules can have 7 types of resources:
Clientside
Serverside
image SVG image<svg:svg>
filter Automated XSL Transform
service Extended XSL Transform
datastore XML data fileWhen will Bush get convict
script XML instruction file
display XSL Transform
hook Set of XSL Transforms
Requesting Resources
Datastores are only requested from services running at that node itself:
Most resources are requested using a URI (Universal Resource Identifier)
image <imagereq function=”uri”>
display <displayreq function=”uri”>
hook <hookreq function=”uri”>
filter (not requested)
datastore
<servicereq function=”http://friend2friend.net/services/bag-read”>
<datastore-name>NCName</datastore-name><itemid>1</itemid><itemid>8</itemid>
</service>
service <servicereq function=”uri”>
script <scriptreq function=”uri”>
Images
Module images are Scalable Vector Graphic (SVG) documents
rdf:about = <uri>
src = <path>
version = <number>
When clients process an <imagereq>, they request this resource by URI from
their F2F soft-system:
ClientClient Soft-Soft-systemsystem
enabled = {0, 1}
<svg:svg>
All resources can take this attribute, but it is not shown
again, for brevity
Where the server can find the SVG file on disk.
<svg:svg>
uri src
<imagereq function=”uri” x=”24” y=”24”/>
Notation!
Required attributes are shown in bold,others are optional
Displays
Module displays are XSL Templates, applied by clients:
rdf:about = <uri>
src = <path>
version = <number>
They are requested by <displayreq> items,
which tells clients to request the appropriate
XSL from the server.
Although all resources except datastores need this attribute,
it is not shown again, for brevity
ClientClient Soft-Soft-systemsystem
uri src
<displayreq function=”uri”>...optional XML...</displayreq>
Hooks
Hooks are identified by URI:
compiled list of handlers
rdf:about = <uri>
<handler namespace = {<uri>, “”, “*”} src =”<path>”/>
On this, modules can hang their own handlers, which link a namespace to an XSLT script:
Soft-Soft-systemsystem
uri src<hookreq><hookreq>
<hookreq function=”uri”>...XML Data...</hookreq>
http://www.altruists.org/ff11
They are explained in detail in presentation /FF11.
<handl
er>
<ha<h
Filters
Module filters, to automate the soft-system, are defined as follows:
rdf:about = <uri>
position = {“bottom”, “exec”, “top”}
http://www.altruists.org/ff9
These are used by the soft system when processing messages and servicereqs as explained in presentation /FF9.
Filters contain one <down> and/or <up> item,which reference the XSLT that implements them,
and optional process-directives or a privilege:
<{up,down} src=<path> privilege = {“*”, 0, 1, 2...} p.d’s />
privilege confers on scripts for a number of crunches (or, with *, an unlimited number) the access permissions of the
module, rather than those of the packet being filtered.
Scripts
privilege = {“*”, 0, 1, 2...}
Module scripts are chunks of XML to be interpreted.
rdf:about = <uri>
src = <path>
default = {“allow”, “deny”}
role = <uri>
These are used by the soft system in a similar way to shell scripts, to automatic actions on system shutdown, installation etc.
This defines the purpose of this script, which is one of a fixed set.
Services
privilege = {“*”, 0, 1, 2...}
Module services augment the core services, detailed as follows:
visibility = {“protected”, “public”, “private”}
output = {“*”, <path>}
rdf:about = <uri>
input = {“*”, <path>}
src = <path>
default = {“allow”, “deny”}
http://www.altruists.org/ff5
The servicereq processing model is explained in detail by /FF5.
Protected services are accessed by a message to the node.
Services can callout to public services without messaging or access control.
Private services are invisible to other soft-
nodes.
midput = <path>Paths to XSDs for runtime validation
Datastores
Datastores are XML files at the soft-node, detailed as follows:
rdf:ID = <NCName>
ServicesServices Soft-Soft-systemsystem
IDsrc
<some XML data>
When will Bush get convict
When will Bush get convict
The identifier exposed to scripts.It does not need to be universally
unique, only unique within this node.
<servicereq function=”http://friend2friend.net/services/bag-read”><datastore-name>fish</datastore-name><itemid>1</itemid>
</service>
Datastores are accessed through the bag-* and xml*
services at the soft node.
schema = <path>
src = <path> Path to a schema to validate this.
Alternative Syntax
Standard (tidy) syntax:
<displayreq function=”uri”>... optional XML ...
</displayreq>
<imagereq function=”uri”/><imagereq>
<function>uri</function></imagereq>
<displayreq><function>uri</function>(<data>... XML ...</data>)
</displayreq>
<hookreq function=”uri”>... required XML ...
</hookreq>
<hookreq><function>uri</function><data>... XML ...</data>
</hookreq>
Two forms are available for the following request items:
<svg:svg>
Expanded (nestable) syntax:
http://friend2friend.net/
If they need privileged accesses to other module’s resources, modules must declare this, so these privileges can be granted on installation.
Module Requirements
http://friend2friend.net/modules/window/
http://friend2friend.net/modules/desktop/
Modules are currently referenced only using URI. Reference by version may be useful for forward compatibility
http://friend2friend.net/modules/dev/
Each module must have an XSD, with its own target namespace.
Module Datatypes
Modules may use xml data defined by other modules,though this means adding that module to the list of requirements. It is usually only helpful for modules which are already required.
Modules services should use F2F elements as arguments if an appropriate one exists, or define their own otherwise.
Summary
Module resources offer complimentary functionality.
Recommended Follow-up: FF14: Software Design
http://www.altruists.org/ff14
Soft-nodes are instances of installed modules.
Most resources are identified by URI and
requestable through XML.
Services Filters
Displays Images
Scripts Hooks
Datastores
uri
Services FiltersDisplays Images
Hooks
Datastores /f2f