Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=APP_CONNECTIVITY_REDESIGN_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

This task is about redesigning the current connectivity model according to the new resource model and improving it so it reaches a stable beta phase.

Since there are too many tasks about server and connectivity,they first need to be categorized, analyzed and scheduled. A clear vision for further procedure is needed - this task is about doing so.

Task requirements

Analyze the current status and what needs to be done for the following:

• The whole connectivity design must be revised (in this task) - what does is consist of, how does the client use the connectivity module, etc.
• Facade - since the resources are being redesigned, the facade needs to be changed. Real time collaboration support should be provided (sync methods).
• Connection list - the connection list in the client needs to be persisted, should provide manipulation ability, connections need to have clear statuses defined.
• Server resource listing - the client needs to have a clear way of getting server resource lists (keeping in mind the security permissions). Also, needs to have filtering, searching, open/close support. This issue affects the server, too.
• Client U.I. - there is currently a tab for the server stuff in the left flap, it must be re-designed and synchronized with our analysis men.
• Security - there is already some user/group model, but no logic is using it. Analyze / design the base security model.

Task result

• In the design - design documentation for every connectivity aspect discussed above. Design diagrams are needed, auto tests are obligatory.
• In the implementation - Achievable schedule of what will be accomplished in what time, considering connectivity. The common design must be implemented as a basis for the next tasks. The tasks which will be implemented should be grouped and (optionally) analyzed.

Implementation idea

• The base.connectivity module currently does not maintain the list of the available connections - they are kept in the corresponding palette. Consider this behavior.
• There is a design draft for the new resource facade after the resource redesign - ​http://pastebin.asteasolutions.net/f444cc8f1. Another idea is that the client implementation of the facade is used by the server resource accesses, and the server-side implementation uses the server resource accesses.
• Connection listing should mainly use the server resource access, so it must be synchronized with other teams' work.

Related

GROUP_RESOURCE_MODEL_REDESIGN_R0

How to demo

Explain the complete model to the teams. Show the working prototypical code.

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.

• 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. 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. 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 : 1st week. 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 : 2nd week. Persisting, listing, editing, password managing, statuses, auto-connect, anonymous log-in, register.
• GROUP_APP_CLIENT_RESOURCES_R0 : 2nd/3rd week. Resource listing, server resources palette related operations, server resource preview, maybe filtering.

Tests

• Base automatic test for the new structure: http://sophie2.org/trac/attachment/wiki/APP_CONNECTIVITY_REDESIGN/ConnectionsPaletteTest.java.

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}