Re: [circle] How are data items stored/forwarded?

[Paul Campbell]

I guess to sum it all up, here's my basic issue with rodrigo's proposed
GUI/DHT interface:

I fail to see where the benefits are.

It just seems to me that the coupling between the GUI and the DHT code
(and between the core DHT and the services modules) becomes so loose that
I'm having trouble envisioning where it gets a whole lot of benefit.

I can see where a plugin interface will have to present 2 pieces of code
whenever a new "application" (or service if you prefer that word) is added:
1. The code to implement the extensions into the core (the unseen mechanical
stuff).
2. The code to present the new service to the user. This is actually one or
more parts since I'm assuming that we retain thecircle's current multiple
GUI capability (and most other systems such as ML-Donkey have this as well).

However, what I'm not seeing is the advantage (if any) of the components
architecture in twisted used for this purpose. As I understand it, the
purpose of the components architecture is to create standardized interfaces,
and then allow mixing of both glue code and multiple interface implementations.
So that for instance (stealing the twisted example):

IAmericanSocket is an interface defining a standard American power receptacle 
(110V, 60 Hz).
AmericanSocket is an implementation of that receptacle.
IEuropeanSocket is an interface defining a standard European power receptacle 
(220V, 50 Hz).
EuropeanSocket is the implementation of it.

Then this is the adapter to go from one to the other:
EuropeantoAmericanSocket(components.Adapter):
    __implements = (IAmericanSocket,)
    def voltage(self):
        return self.original.voltage() / 2
    def frequency(self):
        return self.original.frequency() * (60/50)
components.registerAdapter(EuropeantoAmericanSocket, EuropeanSocket, 
IAmericanSock)

Then to use the European socket with American equipment:

as = AmericanSocket()
eus = EuropeanSocket()
ams = IAmericanSocket(eus)

Then calls to 'ams' will respond just as calls to 'as' would.

In summary, I'm not sure:
1. How componentizing the GUI/core interface helps any.
2. How adapters enter into the picture with respect to GUI components.

To me, it's pretty obvious using the original example of supporting multiple
RPC sending/receiving mechanisms where the components architecture fits in.
But not for the user interface area.