Changes between Version 9 and Version 10 of APP_CONNECTIVITY_REDESIGN

Timestamp:

07/30/09 13:45:20 (16 years ago)

Author:

kyli

Comment:

--

APP_CONNECTIVITY_REDESIGN

@@ -39 +39 @@
 
 = Design =
+
+
  * 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.
+
  * ServerConnection should not be part of the model, but the model should know about pairs (server, user). So, we introduce a new class - Account. It consists of String serverUrl, String userName, String password, String accountName, Boolean autoConnect and Boolean savePassword - the most probable candidates for persisting before client shutdown. Accounts must not know about connections, but every connection should know the account is has come from. So, the new !ServerConnection class has !ConnectionStatus status, String sessionId, Account account and a private instance of a facade. Furthermore, the !ServerConnection has all the methods that the facade interface has, but with one difference: The facade methods return object of type Response<T> and need sessionId, the connection methods return object of type T and do not need sessionId(since the connection has its own id). This way, the connection can read the contents of a response and eventually react to their status(throw error messages, etc). 
- * 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.
 
- * ServerConnection:
-  * Represents a connection to a server, instantiated from a given Account. 
-  * Every connection has 1:1 relation with a client-side facade.
-  * Has the methods that the facade has, which delegate to the facade's ones.
-  * The main difference between a connection and a facade is that the facade needs Session ID for its methods. 
-  * The facade's methods always return objects of type Response, the connection's ones handle the responses and 'unwrap' them.
-  * The facade is not visible to others, only to the connection.
-  * The methods in the !ServerConnection that the facade doesn't have are login(String username, String password), logout(), connect() and disconnect(). The third one is responsible for getting a session ID from the server and instantiating the private facade, the last one is responsible for destroying the facade in the connection and setting sessionId to null.
- * 
- 
+ * 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.
+
+ * 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.
 
 = Implementation =