Changes between Version 11 and Version 12 of APP_CONNECTIVITY_REDESIGN

Timestamp:

07/31/09 11:22:30 (16 years ago)

Author:

kyli

Comment:

--

APP_CONNECTIVITY_REDESIGN

@@ -40 +40 @@
 = Design =
 
+=== Connectivity Redesign ===
 
  * The facade will be changed with the one from the draft (see implementation idea) and it will need sync methods (probably syntToMaster and syncFromSlave). The majority of its methods will return objects of type Response - they contain a result object, response status and eventually status message. This way, if the server cannot serve the client request, it can give some information about the type of the problem.
@@ -47 +48 @@
  * There will be an AccountManager which maintains list of available server accounts. For every acocunt, it will create a corresponding server connection. The connection will not be active before calling its "connect" method. Note that connect is not the same as login - connect just finds an appropriate facade implementation, instantiates it and gets a sessionId from the server. The login then can authorize the user, but some functionalities do not require the user to be authorized. Communicating with the server without logging in will be treated as annonymous connection. The account manager can create new acocunts, provide a list of the current ones, as well as to provide information about their corresponding connection statuses. The idea here is to hide the visibility to the active connections, they should be exposed only to the accesses.
 
- * ServerResourceLocator is a new class, intended to represent a root server access. It is placed in the main.func.servers module, not in the resources module, because we can have more than one server root. It is registered as extension to the resource module, so the app access will be able to delegate to the correct server root when needed.
+ * ServerResourceLocator is a new class, intended to represent a root server access. It is placed in the main.func.servers module, not in the resources module, because we can have more than one server root. It is registered as extension to the resource module, so the app access will be able to delegate to the correct server root when needed. For now it is just a skeleton, will be implemented in the appropriate task. A general idea is that every server root can handle a certain protocol (http://, sophie://, ..) and every top access handles a concrete server address. Inner accesses are responsible for accessing concrete resources.
 
  * The 2 server-related palettes have some logic, like connect/disconnect, getResourceList and openResource, which will be moved to an !OperationDef enum. This will ease the implementing of the palette actions task.
 
  * !ServerConnection will be moved to main.func.servers, since it is not needed in the base module. Account will be placed in the base.connectivity. !ConnectionStatus and Connector will also be moved to the main.func.servers and the connector extension point will be placed there, too.
+
+=== Tasks ===
+ * ''' UNPLANNED_SERVER_RESOURCE_ACCESS_R0 ''' : Server access structure, access cooperation plan, synchronization model, facade. A server connection should be used for every inner access. Someone should be responsible for resource sync, so the facade should be able to provide such methods.
+ * ''' GROUP_APP_CLIENT_ACCOUNTS_R0 ''' : persisting, listing, editing, password managing, statuses, auto-connect, anonymous log-in, register.
+ * ''' GROUP_APP_CLIENT_RESOURCES_R0 ''' : resource listing, server resources palette related operations, server resource preview, maybe filtering.
+
+
 
 = Implementation =