Merging FileManager^? and Community

Both FileManager^? and Community store data structures for individual accounts.

Community stores :

• Identifier
• Password
• Display name
• Description (not used) ?
• Email address (not used) ?
• Home space IVORN (root FileManager^? node)

FileManager^? stores :

• Identifier (for the node)
• A tree of nodes, representing a files and folders in VoSpace^?.

In the current system, all access to files in VoSpace^? are referenced via the Community account identifier.

In order to access a file in VoSpace^?, the client tools are responsible for :

• Locate the Community service from the account identifier
• Call the Community service to request the account data
• Read the 'home space' IVORN from the account data
• Locate the FileManager^? service from the node identifier
• Call the FileManager^? service to access the data

This adds at least two additional SOAP calls to each VoSpace^? access, for little if any real benefit.

At the start of the project, it was not clear if there would be a one to one relationship between Community accounts and FileManager^? trees. In theory, it may have been possible for one Community account to 'own' more than one FileManager^? tree. Or, conversely, one FileManager^? tree to be 'owned' by more than one Community account.

In practice, the way that our services are being deployed means that there is always a one to one relationship between Community accounts and FileManager^? trees. A Community account always has one corresponding FileManager^? tree, and each FileManager^? tree is always 'owned' by a specific Community account.

This means that the original reasons for implementing the Community and FileManager^? functionality in two separate services no longer applies.

As security becomes more of an issue, and we begin to add access controls and authentication to more and more of our services, the extra complexity and additional SOAP calls involved in treating the two services separately will have a significant impact on the performance and reliability of our system.

At this point, it is worth considering merging the two services into one.