Since the vast majority of us do not have net connections large enough to handle such traffic, we need to make some abstractions.
The _ONLY_ way this would work (and I'm NOT talking technically), is if this were rolled in as house to house communication.
DCE has a concept of sending messages to multiple installations, provided those installations are in the database.
So what would need to happen:
(1) a method of synchronizing installation information. sqlcvs could be adapted for this purpose, and in point of fact, in earlier versions of pluto, user databases were synchronized here. However, for this to be feasible, we would need...
(2) A method of providing access control to an installation. This would be an access control list pattern internally, but it would be represented much cleaner up top (who do you want in your circle to be able to expose media, do house commands, etc.)
(3) DCE already provides a Request File command in the General Info Plugin, this can be used to do the actual file transfer. We just need to...
(4) provide the plumbing. SSH might be beneficial for this., just need to work out key exchange.
Now, this presents a problem,
I know not all of you follow the rules when it comes to setting up the system, and you've got your core behind a firewall.
We get around this with Remote Assistance by providing a core-initiated SSH connection to a known server, and the technician then attaches to the provided tunnel on the server. This is not feasible however, for shoving huge amounts of datta down the pipe, as it would then clog the proxy.
But if done right, we can provide a series of screens where:
Connect to a House:
* Provide Installation ID
* Provide your user name
* Provide password
This would prompt a screen on the other end, authorizing the request.
The installation data would be sent to your core, and the system would then be able to send messages.
When a message needs to be sent to another installation, the system will refer to its keys and IP data, to build an ssh tunnel to the other system, if not active, and will automatically shut it off after a timeout.
Now, this is just the plumbing.
Orbiter needs to be extended to handle installation data. and to present the UI for more than one installation. This would also mean, that any changes between the schema of the installed devices, or generated orbiter pieces would also need to be propagated as well. This would happen automatically if all the data attached to an installation were brought into the transfer.
So, it would mean adding at the very least, a screen to switch installations, as well as synchronizing pluto_media data.
As well as doing some screen handling to determine if a file is local or remote, and to trigger download action, etc.
Just thinking out loud.
