CVS update: sierra/docs

From: cvs@openprivacy.org
Date: Mon Jan 29 2001 - 11:55:23 PST

  • Next message: cvs@openprivacy.org: "CVS update: openprivacy/htdocs/notes/reputations"

    Date: Monday January 29, 19101 @ 11:55
    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-serv13792

    Modified Files:
            TODO
    Log Message:
    ..

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

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

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

    CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/sierra/docs/TODO?rev=1.40&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.40&r2=1.39

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

    Index: sierra/docs/TODO
    diff -u sierra/docs/TODO:1.39 sierra/docs/TODO:1.40
    --- sierra/docs/TODO:1.39 Fri Jan 26 05:57:03 2001
    +++ sierra/docs/TODO Mon Jan 29 11:55:23 2001
    @@ -1,9 +1,19 @@
     ********************************************************************************
    -* Last-Modified: $Date: 2001/01/26 13:57:03 $
    -* Version: $Id: TODO,v 1.39 2001/01/26 13:57:03 burton Exp $
    +* Last-Modified: $Date: 2001/01/29 19:55:23 $
    +* Version: $Id: TODO,v 1.40 2001/01/29 19:55:23 burton Exp $
     * Author: Kevin A. Burton ( burton@openprivacy.org )
     ********************************************************************************
     
    +A query of reptuation://SERVER should always return an ontology...?
    + ... maybe this might not make sense if the server has multiple Js each with
    + different bias.
    +
    + - anyway... we need a decent way to determine what a reputation server
    + specializes in. Of course this might also be a RCE that specializes in
    + determining ontology...........
    +
    + hm... still need to think about this!!!
    +
     = ===============================================================================
     = PRIORITY
     = ===============================================================================
    @@ -12,8 +22,6 @@
       necessary for the vitual DOM stuff... How do we do a simple XPath query on a
       complex pubkey mapping.
     
    - - do a report on the S/MIME abstraction.. can we use this?
    -
     - need to register a basic ontology... do this without any XML parsing to begin
       with so that we can have a proof-of-concept.
         
    @@ -29,15 +37,26 @@
     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.
    +- 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
    + OCS you should be able to run queries on the original OCS Server if it happens
    + to be running Sierra or a reputation server. Maybe the OCS feed could contain
    + additional markup for pointing to a Reputation server.
     
     - if a getReputation is called on an object with a reputation:// URI where the
       SERVER is specified... use a Remote object for this. IE:
       reputation://www.slashdot.org/PUBKEY we would forward this to a SOAPClientRCE
       which would have to point to slashdot.
         
    -- Ability to offload certain ontological requests to specific engines.
    +- Ability to offload certain ontological requests to specific engines.
     
    + - FIXME: The ontology of a URL is NOT within the spec anywhere. We need to
    + add this before this can be done.
    +
    +- 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
    @@ -102,7 +121,10 @@
       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

    This archive was generated by hypermail 2b30 : Mon Jan 29 2001 - 11:55:24 PST