Cocoa/Objective-C Complementos Colisiones

Question

Mi aplicación tiene un sistema de complemento que permite a mis usuarios escribir sus propios complementos que se cargan en tiempo de ejecución. Por lo general, esto está bien, pero en algunos casos dos complementos usan las mismas bibliotecas que causarán una colisión entre esos dos.

Ejemplo:

Plugin Un quiere usar TouchJSON para trabajar con JSON y por lo tanto el creador añade el código TouchJSON a la fuente plugin y se pone compila y se enlaza en el binario de complemento. Más tarde, , el complemento B también quiere usar esa misma biblioteca y hace exactamente lo mismo. Ahora, cuando mi aplicación carga estas dos plugins diferentes que detecta esto y escupe una advertencia como esta:

Clase CJSONScanner se implementa en tanto [path_to_plugin_a] y [path_to_plugin_b]. Se usará uno de los dos . Cuál es indefinido

Como mi aplicación simplemente carga complementos y se asegura de que se ajusten a un cierto protocolo, no tengo control sobre qué complementos están cargados y si dos o más usan la misma biblioteca.

Siempre que ambos complementos utilicen la misma versión exacta de la biblioteca, esto probablemente funcionará, pero tan pronto como la API cambie en un complemento surgirán muchos problemas.

¿Hay algo que pueda hacer al respecto?

Answer 1

El sistema de carga de paquetes no proporciona medios para resolver pacíficamente los conflictos de nombres. De hecho, nos dicen que ensure ourselves that the problem doesn't happen, en lugar de qué hacer si sucede. (Obviamente, en tu caso, eso no es posible).

Puede file a bug report con este problema.

Si esto es absolutamente crítico para su aplicación, puede desear tener paquetes en vivo en procesos separados y usar algún tipo de IPC, posiblemente NSDistantObject, para pasar los datos de su programa a los hosts del complemento. Sin embargo, estoy bastante seguro de que esto es una bolsa de daño, por lo que si no tiene interfaces claramente definidas que permitan la distribución en diferentes procesos, podría ser una empresa.

Answer 2

En un modelo de proceso único, la única forma de lidiar con esto es asegurar que el código compartido (más precisamente, las clases Objective-C compartidas) se cargue una vez. Hay dos formas de hacerlo:

• Coloque el código compartido en un marco.
• Coloque el código compartido en un paquete cargable y cargue el paquete cuando el complemento esté cargado si las clases relevantes no están ya disponibles (verifique usando NSClassFromString()). El código del cliente también debería usar NSClassFromString() en lugar de referirse directamente a las clases.

Por supuesto, si no tiene el control de los complementos no puede aplicar ninguno de estos esquemas. Lo mejor que puede hacer es proporcionar pautas apropiadas y posiblemente infraestructura; por ejemplo, en el segundo caso, la aplicación podría gestionar la carga, tal vez especificando una clase para verificar y el nombre de un paquete incrustado para cargar si no está disponible en el del plugin Info.plist.