CVS update: sierra/docs

From: cvs@openprivacy.org
Date: Wed Feb 07 2001 - 16:14:25 PST

  • Next message: cvs@openprivacy.org: "CVS update: sierra/docs"

    Date: Wednesday February 7, 19101 @ 16:14
    Author: burton
    CVSWEB Options: -------------------

    Main CVSWeb: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi

    View this module: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/sierra/docs

    -----------------------------------

    Update of /usr/local/cvs/public/sierra/docs
    In directory giga:/tmp/cvs-serv12704

    Modified Files:
            TODO
    Log Message:
    clean up...

    *****************************************************************
    File: sierra/docs/TODO

    CVSWEB Options: -------------------

    CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/sierra/docs/TODO?annotate=1.46

    CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/sierra/docs/TODO?rev=1.46&content-type=text/x-cvsweb-markup

    CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/sierra/docs/TODO.diff?r1=1.46&r2=1.45

    -----------------------------------

    Index: sierra/docs/TODO
    diff -u sierra/docs/TODO:1.45 sierra/docs/TODO:1.46
    --- sierra/docs/TODO:1.45 Wed Feb 7 03:08:08 2001
    +++ sierra/docs/TODO Wed Feb 7 16:14:25 2001
    @@ -1,29 +1,24 @@
     ********************************************************************************
    -* Last-Modified: $Date: 2001/02/07 11:08:08 $
    -* Version: $Id: TODO,v 1.45 2001/02/07 11:08:08 burton Exp $
    -* Author: Kevin A. Burton ( burton@openprivacy.org )
    +*** Last-Modified: $Date: 2001/02/08 00:14:25 $
    +*** Version: $Id: TODO,v 1.46 2001/02/08 00:14:25 burton Exp $
    +*** Author: Kevin A. Burton ( burton@apache.org | burton@openprivacy.org )
     ********************************************************************************
       
     = ===============================================================================
     = PRIORITY
     = ===============================================================================
     
    -- need at least a prototype plan on how we want to handle pubkeys. This is
    - necessary for the vitual DOM stuff... How do we do a simple XPath query on a
    - complex pubkey mapping.
    +- should the SOAPServerRCE be pointed to another impl RCE which is local? This
    + would be needed to make sure that the SOAPServerRCE works with a
    + SOAPClientRCE.
     
    -- need to register a basic ontology... do this without any XML parsing to begin
    - with so that we can have a proof-of-concept.
    -
    -- should the SOAPServerRCE be pointed to another impl RCE which is local?
    -
    -- Reputation should become an component. It should be served by talon.
    -
     = ===============================================================================
    -= MILESTONE 1 REQUIREMENTS
    += MILESTONES
     = ===============================================================================
     
    - - Use Case 1: Standard JetSpeak SCDS stuff. A1 subscribes to multiple content
    + - Use Case 1: http://pix.comedia.com/OpenPrivacy/20010116/DSCN6054.JPG
    +
    + Standard JetSpeak SCDS stuff. A1 subscribes to multiple content
         sources on a JetSpeek server. A2 then asks the JetSpeek server for the list
         of favorite channels from A1.
     
    @@ -35,7 +30,9 @@
     
            - *PROBLEM* : How does A2 specify a query subset which should return only
               documents within the RSS namespace???
    -
    +
    + - the JetSpeek server should become an RCE which uses the Sierra stuff.
    +
       - Use Case 2: http://pix.comedia.com/OpenPrivacy/20010115/DSCN6049.JPG
     
         - need to build hierarchies of URIs -> Reputations -> Reputations.
    @@ -58,32 +55,44 @@
         Calculation Engines. If the RCEContext specificies a different J... Make
         sure to return the correct Bias RCE.
     
    -= ===============================================================================
    -= MILESTONE 2 REQUIREMENTS
    -= ===============================================================================
    -
    - - CompositeRCE functionality
    - - URL forwarding
    - - Ontology forwarding
    - - Bias forwarding.
    - - RCE Nesting via
    -
       - MeanRCE should become WeightedRCE. This would provide the same functionlity
         as a MeanRCE (by having all opinions as the same weight). The added
         functionaly would that you could change the vote metric that each J has. A
         good example of this would be that anythign that "Fen" says counts as 5
         votes in the ontology of "Privacy".
    -
    -= ===============================================================================
    -= COMPOSITE RCE NOTES
    -= ===============================================================================
    +
    + - Need an abstraction of how to create and manage nyms. The facility needs a
    + way to get the private and public keys for the nym and also determine a new
    + nym based on another nym. This "new" nym could be used temporarily but
    + could also stay with the user for a long period of time with support for the
    + parent nym proving that it created this sub-nym. The system should support
    + basic nyms which are simple to implement but scales to PGP, RSA, etc. When
    + it comes time to rewrite this Sierra to support PGP/RSA we shouldn't have to
    + modify any of Sierra to support this.
    +
    + - RSA authentication with public private key pairs and working signatures.
    + - requires nym management.
    +
    + - CompositeRCE functionality
    + - URL forwarding
    + - Ontology forwarding
    + - Bias forwarding.
    + - RCE Nesting via
    + - cost? $$
    +
    + - Need to create a CompositeRCE component that held other RCEs and used each one
    + intelligently.
    +
    + This could potentially be the default way that a Reputation server is used and
    + it would be configured to use the correct RCE (remote or local).
     
    -Need to create a CompositeRCE component that held other RCEs and used each one
    -intelligently.
     
    -This could potentially be the default way that a Reputation server is used and
    -it would be configured to use the correct RCE (remote or local).
    +
     
    +
    +
    +
    +
     - determine the correct RCE by the type of URI requested. This should allow the
       the administrator (and the object) to deploy the RCE and add some regexps
       based on the URI requested. A good example of this if you get an RSS feed via
    @@ -104,49 +113,10 @@
     - When a getReputation is requested for a certain URI we need to be able to
       forward this to a more appropriate engine. This should be
           
    -- specify cost of a RCE so that it isn't used as often??
    -
    -- is it possible to deploy a composite object which blends the responses from
    - multiple reputation servers??? (this might be something we need in the
    - future).
    -
    -- Example properties config:
    -
    - talon.component.DEFAULT_RCE.classname=org.openprivacy.sierra.rce.CompositeRCE
    - talon.component.DEFAULT_RCE.property
       
     = ===============================================================================
    -= REPUTATION CALCULATION ENGINE (RCE) REQUIREMENTS/NOTES
    -= ===============================================================================
    -
    -- Should we have a SOAPClientRCE?
    -
    -- All RCEs are registered with their own namespace. This way a getReputation
    - request can specify a specific RCE namespace (or instance). Should this be
    - included in a ReputationContext? getTargetRCE()???
    -
    - - Should be able to pull this out of Talon
    - - should a Talon component return a URI?
    -
    - - Should they also get an instance name???
    -
    -- How should we define the query() mechanism which is provide within the RCE
    - interface? This would take a XPath query as a param and query a virtual XML
    - document which could be mapped to SQL/flat files/etc within the infomediary layer
    -
    - - we need a basic proof-of-concept that this is possible.
    -
    -- An RCE needs to have support for event based queries... This should go into
    - the RCE interface. This would provide support for systems that deliver
    - reputations to a target when a certain query is accepted.
    -
    -= ===============================================================================
     = GENERAL REQUIREMENTS
     = ===============================================================================
    -
    -
    -- write a MeanRCE ReputationCalculationEngine. This should be the default which
    - ships with Sierra.
     
     - Example Virtual XML document... this should be just like the Reputation,
       Ontology, Value APIs.



    This archive was generated by hypermail 2b30 : Wed Feb 07 2001 - 16:14:26 PST