On Wed, Jul 14, 2010 at 02:31:46AM -0000, [email protected] wrote:
> I'll answer whatever questions I can. :)
Oh, I have some questions...
I asked some questions in the form of suggestions, well, don't take them
seriously,
I only ask, not really propose anything. However I'm ready to hear you
about what I'm wrong with.
Here, what I have discovered so far:
There are transport factories in twisted, not defined as such, but really they
are,
like tcp.Port and tcp.Connector.
They interface with protocol factories. That interface is asymmetric between
server protocol factory and client protocol factory. Well, the implementation
of client's side protocol factory and server's side should differ, but why
should interfaces?
That is okay, while you only have different and asymmetric transport factories
the ones for client transports and the others for server transports.
But is there really something in created and connected transport,
that makes it server's or client's ? I guess nothing, except protocol instance
attached.
Q: Why should protocol factory interface "bother" about client/server dichotomy?
For example, why should I be limited to only using PBClientFactory with
connectXXX()
variants of transport factories?
Why should I do not want (under some crazy circumstances) to use
reverse-connects
and run PBServerFactory with connectXXX()?
Well, maybe not PB, but what about other protocols?
Should it work? Well, I suppose, it would break if you try now, but is
is supposed to be that asymmetric?
And after all, there is absolute symmetry in UDP-based transports.
Q: Consider socketpair() variant - a pair of completely symmetric mutually
connected sockets.
Should I provide transport factory for use with server protocol factories
and another transport factory for use with client protocol factories?
That idea sounds stupid to me, there can be no difference in the implementation,
except in the interfaces to protocol factories.
I see there are some code, that can be moved from tcp.Port and tcp.Connector
to some common base class of an abstract transport factory. That class could
interfere with protocol factory without knowing whether it is server or client.
Protocol factory already knows about it's own asymmetry.
I do identify the events, that protocol factory receives from transport factory
as these,
please correct me if I'm wrong:
global (factory-context) events:
- start factory doStart
- entering transport creation phase startedConnecting <server: when
bind&listen succeeds why does anybody
not invoke
something like startedListenig ?>
- stop factory doStop
per transport connection events:
- on transport creation <none exists?why?> <after
connect() or listen() returns result, at this point
we may decide
to prevent further transport instantiation,
especially if
we are server-side protocol factory>
- transport creation failed clientConnectionFailed <server: direct
analogy - accept() may return an error,
but that event
not exists for server. why?>
- transport created succesfully buildProtocol <a request to
build a protocol instance implies, that
transport
instance have been succesfully created. or not?>
- build protocol buildProtocol
- after transport and protocol creation clientConnectionMade <in
t.s.pb.PBXXXXFactory, event sent by protocol instance,
name not
defined in any Interface, why not?>
- transport closed clientConnectionLost <why not define
this for server too to be consistent?>
They are not client/servers asymmetric as I see them, but have asymmetric names
in twisted
and sometimes when server variants exists, they have no fixed names defined in
Interface classes :(
What is the difference between doStart and startedConnecting (together with
imaginary startedListening)?
And who is responsible for sending which events? That is not defined in
documentation.
What do you think about these names:
doStart()
transportFactoryStarted()
onBeforeTransportCreate()
connectionFailed()
buildProtocol()
connectionMade()
connectionLost()
doStop()
Well, I understand, you will veto them arguing by lot of code using old names,
but I am interested to know will they break the abstraction of protocol factory?
Can please anyone explain the asymmetry of the interfaces of protocol factories
and tell how can it be useful for me.
Thanks for your time.
Alexey.
--
с уважением,
Алексей Шпагин
системный администратор
цеха передачи данных
технического центра телекоммуникаций
ОАО "ВолгаТелеком"
филиал в Удмуртской республике.
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
