Changes between Version 14 and Version 15 of JuergeN


Ignore:
Timestamp:
19.08.2011 20:41:57 (9 years ago)
Author:
JuergeN
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • JuergeN

    v14 v15  
    11[[JuergeN|Jürgen Neumann]] <j.neumann{at}junes{dot}eu> 
    22----- 
     3[[PageOutline]] 
    34 
    4 [[PageOutline]] 
    5 {{{ 
    6 Striked-through items have been transfered to ticket-system or elsewhere or are obsolet. 
    7 }}} 
     5 * [/Notes] 
     6 * [/PR-Mail] 
     7 
    88---- 
    9  
    10 = Julian Priest, Wed, 3 Aug 2011 = 
    11 >  
    12 > hey juergen, 
    13 >  
    14 > thanks have installed and it all looks good. 
    15 >  
    16 > contacts import would be a good feature for mapping your personal 
    17 > networks - and nice to not be posting it to the world! 
    18 >  
    19 > the html interface seems really good and reckon a .deb installer would 
    20 > be a boost too. 
    21 >  
    22 > cheers 
    23 >  
    24 > /julian 
    25  
    26 = Notes from 18.07.2011 jpn,jri,dgf = 
    27  * Product Name DeepaMehta 4 
    28   * ~~New DM without properties is called DM4~~ 
    29   * ~~Replace DeepaMehta 3 in Github to DeepaMehta~~ 
    30   * ~~TopicType URIs shall be changed to dm4.xxx.yyy.zzz~~ 
    31   * ~~Modulnames (e.g. TypeEditor) shall be called DeepaMehta 4 TypeEditor~~ 
    32  * Trac 
    33   * ~~Enable Email for all purposes (Notification, Account, etc.)~~ 
    34   * ~~Connect to GitHub~~ 
    35  * Is OWL useful for DeepaMehta ? 
    36   * Think about OWL when dealing with XML export 
    37  * Wording 
    38   * ~~Standard DeepaMehta Webclient is called "DeepaMehta Webclient"~~ 
    39   * ~~DeepaMehta Application Framework is called "DeepaMehta Server"~~ 
    40   * DeepaMehta Components are called "DeepaMehta REST Server, DeepaMehta CORE Server, etc." 
    41   * OSGi Bundle = Maven Modul = DeepaMehta Plugin 
    42   * There may be a special DeepaMehta Desktop Edition in the future 
    43   * ~~Rename DeepaMehta Server Plugin to DeepaMehta Webservice Plugin~~ 
    44   
    45  
    46 = Notes from 16.07.2011 = 
    47  * ~~Define Words for DeepaMehta Application Server and DeepaMehta Standard GUI to clearify~~ 
    48  * Write Documentation 
    49  * ~~Clearify License Terms and Fullfillment in distribution!~~ 
    50  
    51  
    52 = Notes from Gilleleje 09./10.07.2011 = 
    53  * HTML5 approach for user-interface is the right direction 
    54  * A text based interface would be cool for testing (Eclipse?) 
    55  * What can we learn from LDAP especially in terms of LDIF and syncronisation? 
    56  * We need a glossary. What is a workspace (=domain?)  
    57  * Associations may also be functions or transformations. How could this be handled in the user-interface? 
    58  * Workspaces could suggest predefined ACL settings like a private, family or job workspace 
    59  * What hooks do we need? cron, timer, event handler ...  
    60  * Can we use OWL? What would be missing? 
    61  * Describe a valid file for ObjectClass, AssociationType and their instances 
    62  * Binary Content shall be stored in filesystem or in database like Couche-DB (including full-text index and versioning) 
    63  * make concept for versioning (of content) 
    64  * Define more pre-defined edges (like order or critical path) 
    65  * change edges to Bezier curves 
    66  * adding weight to edges could be useful 
    67  * Do we switch to a new Version Name DeepaMehta 4? 
    68  
    69 == Urgently Missing Concepts for Operational Platform == 
    70  
    71 == Security Concept == 
    72 Especially today with all the myfaces and other social networks out there, the sensitivity for data security is widely rising. Not just for that reason, but also because it is my personal precondition, I want DeepaMehta to be a very secure application. Therefore I think that the following concepts should all go into the core of DeepaMehta and no workarround should be implemented at any time or for any reason. In a later version we might even implement a GPG like public private key data encryption. 
    73  
    74  
    75 === User Concept === 
    76  
    77 Every operation in DeepaMehta should be done by an identified user. Users (and groups) should be handled through UID (and GID) 
    78  
    79  
    80 {{{ 
    81  SYSTEM 
    82    | 
    83   root  
    84    | 
    85   user(n) 
    86    | 
    87  anonymous 
    88    | 
    89  nobody(?) 
    90 }}} 
    91  
    92 Every user should have their own group (like in UNIX) 
    93  
    94 === Secure Passwords === 
    95  
    96 Passwords should be stored securely, hashes with salt etc. (do research) 
    97  
    98 === Operations === 
    99  
    100 Which operations does the server offer/allow on objects and associations? 
    101 We need to define a list of valid operations for Topics Associations and ~Types. Those are: 
    102  * create (createTopic / createAssociation / createTopicType / createAssociationType) 
    103  * update/modify 
    104  * delete 
    105  * get/read (by ID/Value) 
    106  * search/scan 
    107  * navigate (what's related?) 
    108  * still missing: equals/compare(true/false) 
    109  
    110 === Roles === 
    111  
    112 Valid operations should be defined/idenfied through roles (via Tokens), like 
    113  
    114  * SYSTEM 
    115  * administrator 
    116  * creator 
    117  * owner 
    118  * member (workspace) 
    119  * peer/manager/editor 
    120  * everyone (=every user) 
    121  * anonymous 
    122  
    123 Roles should be assined to users and groups. 
    124  
    125  
    126 === Attributes === 
    127 Every object should have a set of inherent attributes ( which may be properties or associations), e.g. 
    128  * create time 
    129  * modify time 
    130  * access time 
    131  * not property: creator -> association 
    132  * not property: owner -> association 
    133  * ro 
    134  * not property: hidden -> association (viewable e.g. based on context) 
    135  * private (interface shortcut for ACL) 
    136  * isolated (=object cannot be associated) (insterface shortcut for ACL) 
    137  * not property: label -> association -> name/label 
    138  
    139 === Access Control Lists === 
    140 Every object (nodes and edges) shall have inherent ACLs (properties) to define permissions on this object.  
    141  * Group A: read only (ro) 
    142  * Group B: read write (rw) incl. delete 
    143  * everyone: read only (ro) 
    144  * user(n): associate (a) (create an association towards this object) 
    145  
    146 Questions: How do ACLs relate to edges? May one see the association to a hidden object? 
    147  
    148 ACLs can be set on user and group level. 
    149  
    150 === Operation Control List === 
    151 Especially for TopicType and WorkSpace, we need to define who may do what by role and operation on the object. It defines e.g if  user may create or search an instance of an object, user may join a certain workspace, create (and send) an email (function) or in general who may use domain specific functions.   
    152 The operation is to a certain role:  
    153   
    154  * role: operation 
    155  * member: createInstance  
    156  
    157 === Locations === 
    158  
    159 Operations could be limited through location address (localhost, 192.168.0.1, etc.), Just like in Apache or 'MySQL' 
    160 Location shall be part of the Token to allow certain operations only from localhost, or IP XXX.YYY.ZZZ.ABC 
    161 e.g. when uploading a file it is important to know if you work on localhost (just add a link) or if working on a remote server then open upload dialogue. 
    162  
    163 === Token === 
    164  
    165 Server creates Token for user and validates the token (like Kerberos or OpenAuth).