2010-10-27 10 views
10

He estado jugando con el marco retorcido durante aproximadamente una semana (más por curiosidad en lugar de tener que usarlo) y ha sido muy divertido hacer una programación de red asíncrona impulsada por eventos.¿Por qué hay una necesidad de Twisted?

Sin embargo, hay algo que no entiendo. La documentación retorcida comienza con

Twisted es un marco diseñado para ser muy flexible y le permite escribir servidores potentes.

Mi duda es: ¿Por qué necesitamos una biblioteca basada en eventos para escribir servidores poderosos cuando ya hay implementaciones muy eficaces de varios servidores?

Seguramente, debe haber habido más de un par de implementaciones concretas que los desarrolladores retorcidos tenían en mente al escribir esta biblioteca I \ O impulsada por eventos. ¿Que son esos? ¿Por qué exactamente se hizo retorcido?

+2

¿Por "implementaciones" quieres decir "usos"? Estoy familiarizado con dos significados de la palabra implementación: escribir software para lograr una tarea en particular; o para implementar software en una configuración particular. –

+0

Sí, me refería al anterior - software de escritura para lograr una tarea en particular. –

Respuesta

13

En un comentario sobre otra respuesta, dices "Se supone que todas las bibliotecas tienen ...". "Supuesto" por quién? Tener casos de uso es sin duda una buena manera de definir sus requisitos, pero no es la única. Tampoco tiene sentido hablar sobre los casos de uso para todos los Twisted a la vez. No hay ningún caso de uso que justifique todas las API en Twisted. Hay cientos o miles de casos de uso diferentes, cada uno de los cuales justifica una subdivisión menor o mayor de Twisted. Estos fueron y vinieron durante los años de desarrollo de Twisted, y no se ha intentado mantener una lista de ellos. Puedo decir que trabajé en una parte de Twisted Names para tener un tema para un trabajo que estaba presentando en ese momento. Implementé el analizador vt102 en Twisted Conch porque estoy obsesionado con las terminales y quería un proyecto divertido que las involucrara.Y implementé la compatibilidad con IMAP4 en Twisted Mail porque trabajé en una compañía que desarrollaba un servidor de correo que requería un control más estricto sobre la tienda de correo que cualquier otro servidor IMAP4 en ese momento.

Así que, como puede ver, las diferentes partes de Twisted se escribieron por razones muy diferentes (y solo he dado ejemplos de mis propios motivos, no de los motivos de ningún otro desarrollador).

La razón inicial de que un programa se escriba a menudo no importa mucho a la larga. Ahora el código está escrito: Twisted Names ahora ejecuta DNS para muchos nombres de dominio en Internet, el analizador vt102 me ayudó a conseguir un trabajo y la compañía que impulsó el desarrollo de IMAP4 está fuera del negocio. Lo que realmente importa es qué cosas útiles puedes hacer con el código ahora. Como señala MattH, la plétora de funcionalidades resultantes ha resultado en una biblioteca que (quizás de forma única) aborda una amplia gama de problemas interesantes.

+0

Me encanta esta respuesta. –

+0

También tenga en cuenta que no solo los casos de uso influyen en un proyecto, sino que otros tipos de requisitos, como los requisitos no funcionales (disponibilidad, seguridad, etc.), también pueden tener mucho más que decir que simples casos de uso. – Coyote21

7

¿Por qué necesitamos una biblioteca basada en eventos para escribir servidores potentes cuando ya hay implementaciones muy eficientes de varios servidores?

Así que parafraseando: no se puede imaginar por qué alguien necesitaría un conjunto de herramientas cuando ya existan productos dyecast?

Supongo que nunca ha necesitado bloquear una puerta de enlace de protocolo, p.
- escriba un daemon a md5 archivos locales bajo demanda en un socket Unix
- interrogue un software usando udp y exponga las estadísticas a través de http.

Escribí una pequeña prueba de concepto para el segundo ejemplo de una pregunta aquí en SO en un handful of minutes. No podría hacer eso sin retorcerme.

¿Has mirado en: ProjectsUsingTwisted?

+0

Gracias por su respuesta. Sin embargo, no entiendo por qué se creó Twisted en primer lugar. Se supone que cada biblioteca tiene un par de implementaciones concretas; en este caso, ¿qué son? –

+2

Hay bibliotecas de middleware que no tienen una implementación específica y/o uso predestinado, y están destinadas a ser lo suficientemente generales para que otras aplicaciones usen el middleware, en lugar de utilizar directamente sockets u otras cosas de bajo nivel. – Coyote21

5

Más sobre "por qué": (descargo de responsabilidad: No soy un desarrollador de Twisted proper), es necesario tener en cuenta la alta edad de Twisted (en relación con Python). Cuando se escribió Twisted, no existía la poderosa biblioteca de no bloqueante activada por red/eventos, escrita alrededor del reactor pattern (casi todos usaban threads en aquel entonces). El caso de uso inicial de Twisted era un gran juego de varios jugadores, aunque los detalles de este juego parecen haberse perdido en el tiempo.

Desde los orígenes, como sugiere el enlace de @ MattH, una gran cantidad de varios servidores de red escritos en Python se basa en Twisted.

+0

Un pequeño rasguño: a pesar de la denominación, creo que la arquitectura de Twisted se asemeja más al patrón del proactor que al patrón del reactor. – mithrandi

4

This PyCon talk por el creador de Twisted debería darle respuestas.

Ha cambiado mi opinión sobre Twisted. Antes lo veía como una enorme pieza de software con interfaces y nombres raros, dos cosas que a muchos desarrolladores no les gustan, pero que en realidad son solo cosas superficiales, y ahora que he visto la historia y el asombroso número de casos de uso, lo respeto mucho. La vida es corta, necesitas Twisted :)

+0

Desafortunadamente, el blip ha eliminado ese video :( –

Cuestiones relacionadas