Seeking for a good web engineer.

Hi, Everyone, Elgg is a powerful well-written and documented open source program, designed as a sort of social network. It is a good basis for managing memberships, communications with and between members, storing all sorts of data, and adding functions like member ratings, etc. We will be modifying it in many ways so that it will fulfill our needs. Like any program, elgg in its standard form is based on one set of databases hosted in 1 place. We will change the way it handles data, so that it is hosted on several 'nodes', in different geographical locations. These nodes will work together so that they 'look' like a single node to the rest of the elgg code. Once this is achieved, we will be able to make any changes we like to elgg data management, without that affecting the rest of the elgg features in any way. When I was a system designer and programmer (pre-internet) we would have used subroutines for all program functions. That means that changes to the way programs operate would be localized within subroutines and be much easier to implement and debug and test. In all my programs, one subroutine would do all the I/O. It would be called using parameters, and return the required data to the program. The other parts of the program therefore did not know or care how the subroutine worked! This was known as the 'black box' principle. elgg will 'know' the location of every user, based on the telephone dialling code for that user. For example, I am in Victoria, Australia,so my dialling code is 613000 (padded out to 6 digits). Each node will host a number of codes. We must be able to 'split' nodes that grow too big, so they remain a manageable size. Every node will host the same code logic, and the same database structures, but with different members. The data managed by every node will be mirrored on one and preferably two other nodes, preferably remote. So if one node is off line or damaged for any reason, the system can quickly recover. In addition to the various 'nodes' there will be one central database (CDB), which stores the fixed data of each user, in a very secure way. Things like name, email, location, username and password, etc. These files will be relatively small since they contain just the data necessary to identify someone. (there will be more data stored here, but that can wait). The CDB will be continually backed up to various locations including off-line. We will also be in touch with clubs, venues (eg tennis clubs or other places) and people interested in running tournaments. Their data will be stored in extra SQL databases in the nodes. Let me know if you have full understand and have confidence in yourself.