FLOWS

From Flows

(Redirected from Main Page)
Jump to: navigation, search

Contents

What is Flows?

Flows is a mechanism for taking networks that were not initially designed together and integrating them into a single communicative complex system.

Flows could be thought of as an API for APIs, or as a meta-API which enables everything to be interoperable, without the extra overhead of coordination costs. Flows makes it possible for the development of interoperability in parallel workgroups, which greatly increases flexibility, diversity, and rapidity of development.

A diagram of Flows is on http://prezi.com @ http://prezi.com/nra5d2vmful6/

Concepts

Flows uses the language and concept of a river as a metaphor and ontology for information processing.

Sources -> Tributaries -> Reservoirs -> Flows -> Delta -> Mouths

Sources of information are available as tributaries which can be stored in reservoirs and then hybridized into "mashups" to define flows which is then sent out via a delta into mouths.

Architecture

Basic Architecture

The Flows architecture deploys the crucial concepts of "plurality" and "diversity":

  • Plurality - Components should be as small as conceivably possible and there should be a lot of them. If your component does two things, then it should be rewritten into two components.
    • There are many ways to implement something. Flows allows this manifold development.
    • Components are connected in a many-to-many fashion "horizontally".
    • Components are context-aware and can communicate information about themselves and their environment.
  • Diversity - Flows does not care about the internals of your component, only its communication with other components. Consequently,
    • Flows components can be coded in any language.
    • Flows components can be served by any http:// server.
    • Flows components do not distinguish between local components and remote components.(eg "localhost" and remote server)
      • This is true if component addressing is via http:// (ex. localhost or IP/DNS remote host).
      • This is true if component addressing is via filesystem path (ex. local filesystem or mounted pseudo-local filesystem via nfs, FUSE, etc.).

Design

The simplest possible flows component implements the following.

  • listens for requests (extensible for future development)
    • REST (default)
    • AMF
    • etc.
  • returns responses (extensible for future development)
    • XML (default)
    • HTML
    • JSON
    • TXT
    • JPG, PNG, etc.
  • a "sip" method that returns at least the following:
    • basic response metadata including the flows version to which the response form corresponds:
      • "URI" is a reference for this object (e.g. a URL)
      • what request types the component will respond to
      • what response types the component can return
      • usage information
        • what parameters (incoming variables) the component will accept
        • what the default response is (usually is the same as "sip")
        • what the default response type is (suggested: XML)
        • Description human-readable text with usage explanation

XML: 

      <response flows_version=".1">
             <URI>http://blahblahblah</URI>
             <request_types>
                     <request_type>HTTP GET</request_type>
             </request_types>
             <response_types>
                     <response_type>XML</response_type>
                     <response_type>HTML</response_type>
             </response_types>
             <usage>
                     <parameters>
                             <param>response_type</param>
                     </parameters>
                     <default_response>sip</default_response>
                     <default_response_type>XML</default_response_type>
                     <description>
                     This Flows component will echo back any text sent to it on the HTTP GET querystring, 
                     using the response_type specified by the requestor.
                     </description>
             </usage>
      </response>

JSON: 

   {
       response:{
           flows_version:0.1,
           URI:'http://blahblahblah',
           request_types:{
               request_type:'HTTP GET'
           },
           response_types:{
               response_type:[
                   'XML',
                   'HTML'
               ]
           },
           usage:{
               parameters:{
                   param:'response_type'
               },
               default_response:'sip',
               default_response_type:'XML',
               description:'This Flows component will echo back any text sent to it on the HTTP GET querystring,
                            using the response_type specified by the requestor.\n '
           }
       }
   }

.

RFC Draft

NECESSARY information for RFCs and Development

Code

Flows Mercurial Work-Process

Development

Flows Watercoolers

Flows IRC

Flows Wiki (http://flows.panarchy.com)

Purposes:

  • Flows concepts and explanations
  • Flows architecture documentation, design, whitepapers, RFCs, etc.
  • Flows demo application (FlowShed?) and components development

Flows Timeline

  • 06/05/2009 setup Flows wiki
  • 06/09/2009 setup flows-dev on code.google.com
  • 06/09/2009 started coding with mercurial revision control
  • 06/16/2009 Rick and Paul solidify Mercurial work-process
  • 06/19/2009 created Flows development "HowTo"
  • 06/25/2009 successfully generated documentation
  • 07/20/2009 tested XML output against FLOWS DTD
  • 08/15/2009 began developing flows components for common webservices and applications
  • 09/24/2009 Roger and Paul made significant progress on the architecture and RFC


.

<noscript> This page uses Javascript to show you a Timeline. Please enable Javascript in your browser to see the full page. Thank you. </noscript>

Participants


Resources

Similar Projects

Ideas

Retrieved from "http://flows.panarchy.com/index.php?title=FLOWS"
Personal tools