[ NemesisRD 1.x ] Carga <proceso>.config excluyente sobre el general
4 views
Skip to first unread message
Eduardo Ramos Testillano
May 17, 2010, 10:00:11 AM5/17/10
to nemesi...@googlegroups.com
Hola,
En la sdp::Application, veo que haces un if-else con prioridad sobre el .config del proceso.
Si existe dicho archivo, ya no abres el general (esta en el else).
Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.
Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos.
De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration & sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro.
Un saludo
-- En la sdp::Application, veo que haces un if-else con prioridad sobre el .config del proceso.
Si existe dicho archivo, ya no abres el general (esta en el else).
Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.
Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos.
De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration & sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro.
Un saludo
--
Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
Cisco
May 17, 2010, 10:19:18 AM5/17/10
to NemesisRD 1.x
Hola.
La idea original fue implementarlo como propones, pero se generaba un
código spaguetti muy difícil de mantener y que aporta muy poco, además
de que hace mucho más difícil estudiar los errores de configuración.
En cuanto a hacer público el objeto de nemesis::Configuration usado
para configurar todos los subsistemas no es posible, porque se crea y
se destruyen en el mismo método, es decir, se crea, se carga la
configuración correspondiente, se establecen los valores y se
destruyen el objeto.
Si quieres obtener algún valor de la aplicación, seguramente podrás
preguntarlo a la instancia concreta sobre la que se aplica el
parámetro en cuestión.
Un saludo.
On May 17, 4:00 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> En la sdp::Application, veo que haces un if-else con prioridad sobre el .config del proceso.
> Si existe dicho archivo, ya no abres el general (esta en el else).
> Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.
> Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos.
> De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration & sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro.
> Un saludo--
>
>
>
> 8KViewDownload
La idea original fue implementarlo como propones, pero se generaba un
código spaguetti muy difícil de mantener y que aporta muy poco, además
de que hace mucho más difícil estudiar los errores de configuración.
En cuanto a hacer público el objeto de nemesis::Configuration usado
para configurar todos los subsistemas no es posible, porque se crea y
se destruyen en el mismo método, es decir, se crea, se carga la
configuración correspondiente, se establecen los valores y se
destruyen el objeto.
Si quieres obtener algún valor de la aplicación, seguramente podrás
preguntarlo a la instancia concreta sobre la que se aplica el
parámetro en cuestión.
Un saludo.
On May 17, 4:00 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> En la sdp::Application, veo que haces un if-else con prioridad sobre el .config del proceso.
> Si existe dicho archivo, ya no abres el general (esta en el else).
> Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.
> Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos.
> De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration & sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro.
> Un saludo--
>
>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> firma.jpg
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> 8KViewDownload
Eduardo Ramos Testillano
May 17, 2010, 11:00:49 AM5/17/10
to nemesi...@googlegroups.com
Hola,
En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run():
configuration.load (configGeneral);
configuration.load (configParticular, true /*accumulate*/);
simplemente comprobar la existencia antes de hacer la carga y poco más.
Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando.
Necesitaría dicha funcionalidad para la fase II de HTE.
Un saludo
En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run():
configuration.load (configGeneral);
configuration.load (configParticular, true /*accumulate*/);
simplemente comprobar la existencia antes de hacer la carga y poco más.
Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando.
Necesitaría dicha funcionalidad para la fase II de HTE.
Un saludo
--
Cisco
May 18, 2010, 1:30:19 AM5/18/10
to NemesisRD 1.x
Hola.
Siempre puedes re-escribir el tratamiento para darle el tratamiento
que precises. Si requieres ese tratamiento puedes hacerlo
en tu parte de la aplicación.
Un saludo.
On May 17, 5:00 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run():
> configuration.load (configGeneral);
> configuration.load (configParticular, true /*accumulate*/);
> simplemente comprobar la existencia antes de hacer la carga y poco más.
> Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando.
> Necesitaría dicha funcionalidad para la fase II de HTE.
> Un saludo
> El 17/05/2010 16:19, Cisco escribió:Hola. La idea original fue implementarlo como propones, pero se generaba un código spaguetti muy difícil de mantener y que aporta muy poco, además de que hace mucho más difícil estudiar los errores de configuración. En cuanto a hacer público el objeto de nemesis::Configuration usado para configurar todos los subsistemas no es posible, porque se crea y se destruyen en el mismo método, es decir, se crea, se carga la configuración correspondiente, se establecen los valores y se destruyen el objeto. Si quieres obtener algún valor de la aplicación, seguramente podrás preguntarlo a la instancia concreta sobre la que se aplica el parámetro en cuestión. Un saludo. On May 17, 4:00 pm, Eduardo Ramos Testillano<era...@tid.es>wrote:Hola, En la sdp::Application, veo que haces un if-else con prioridad sobre el .config del proceso. Si existe dicho archivo, ya no abres el general (esta en el else). Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos. De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration & sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro. Un saludo-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico anemes...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico anemesisrd-1...@googlegroups.comPara tener acceso a más opciones, visita el grupo enhttp://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDownload--
Siempre puedes re-escribir el tratamiento para darle el tratamiento
que precises. Si requieres ese tratamiento puedes hacerlo
en tu parte de la aplicación.
Un saludo.
On May 17, 5:00 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run():
> configuration.load (configGeneral);
> configuration.load (configParticular, true /*accumulate*/);
> simplemente comprobar la existencia antes de hacer la carga y poco más.
> Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando.
> Necesitaría dicha funcionalidad para la fase II de HTE.
> Un saludo
Eduardo Ramos Testillano
May 18, 2010, 9:06:05 AM5/18/10
to nemesi...@googlegroups.com
ya lo se, pero se trata de intentar que actue igual que la otra
plataforma para homogeneizar comportamientos de configurabilidad.
un saludo
un saludo
El 18/05/2010 7:30, Cisco escribió:
Hola. Siempre puedes re-escribir el tratamiento para darle el tratamiento que precises. Si requieres ese tratamiento puedes hacerlo en tu parte de la aplicación. Un saludo. On May 17, 5:00 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
Hola, En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run(): configuration.load (configGeneral); configuration.load (configParticular, true /*accumulate*/); simplemente comprobar la existencia antes de hacer la carga y poco más. Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando. Necesitaría dicha funcionalidad para la fase II de HTE. Un saludo El 17/05/2010 16:19, Cisco escribió:Hola. La idea original fue implementarlo como propones, pero se generaba un código spaguetti muy difícil de mantener y que aporta muy poco, además de que hace mucho más difícil estudiar los errores de configuración. En cuanto a hacer público el objeto de nemesis::Configuration usado para configurar todos los subsistemas no es posible, porque se crea y se destruyen en el mismo método, es decir, se crea, se carga la configuración correspondiente, se establecen los valores y se destruyen el objeto. Si quieres obtener algún valor de la aplicación, seguramente podrás preguntarlo a la instancia concreta sobre la que se aplica el parámetro en cuestión. Un saludo. On May 17, 4:00 pm, Eduardo Ramos Testillano<era...@tid.es>
wrote:Hola, En la sdp::Application, veo que hace s un if-else con prioridad sobre el .config del proceso. Si existe dicho archivo, ya no abres el general (esta en el else). Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos. De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration &am p; sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro. Un saludo-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico anemes...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico anemesisrd-1...@googlegroups.comPara tener acceso a más opciones, visita el grupo enhttp://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDown load-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDownload
--
Cisco
May 18, 2010, 9:20:34 AM5/18/10
to NemesisRD 1.x
Hola.
Primera idea: NemesisRD.sdp y NemesisRD.comm tienen varios valores que
vienen con un valor por defecto y por lo que nadie tendrá que
preocuparse
en el 99% de los casos.
Ahora supón que implementamos el sistema que tu propones y tenemos un
archivo de configuración global con los valores:
AA = 100
BB = 200
CC = 300
DD = 400
y ahora el archivo particular, en el que sólo configuras el nuevo
valor de DD:
DD' = 333
Qué buen sistema!!
Pero ahora imagina que quieres que AA no tenga ningún valor, es decir,
que tome el valor que tenga la plataforma pero como el global
tienes AA=100, ¿cómo indicas que en tu caso particular no quieres que
AA tome ningún valor?, es decir, que quieres que AA se quede con el
valor por defecto que estableza por defecto la plataforma.
La solución más directa es indicar un número mágico!!! ¿-1, -666, 0,
"periquito", ""?
Así que con el sistema que propones una vez que la entrada exista en
la configuración global, dependes de valores mágicos,
lo que viene a indicar que no es una solución-completa, lo que viene a
indicar que no es aconsejable usarlo en una plataforma.
Creo que hay que intentar homogeneizar, pero sólo en las cosas útiles.
De todas formas si sigues necesitando usarlo en tu proceso creo que
dispones de todas las herramientas para solucionar
el problema, sin que esta solución tenga que estar integrada en la
plataforma.
Un saludo.
On May 18, 3:06 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> ya lo se, pero se trata de intentar que actue igual que la otra plataforma para homogeneizar comportamientos de configurabilidad.
> un saludo
> El 18/05/2010 7:30, Cisco escribió:Hola. Siempre puedes re-escribir el tratamiento para darle el tratamiento que precises. Si requieres ese tratamiento puedes hacerlo en tu parte de la aplicación. Un saludo. On May 17, 5:00 pm, Eduardo Ramos Testillano<era...@tid.es>wrote:Hola, En plataforma, la carga se hace como te digo. Quizá bastaría con que tu clase configuration, tuviese metodo load con parametro "bool accumulate = false" por defecto, que permitiese acumular parametros cargando N archivos (N=2 en nuestro caso). Con eso, no sería necesario encadenar ningun if en tu run(): configuration.load (configGeneral); configuration.load (configParticular, true /*accumulate*/); simplemente comprobar la existencia antes de hacer la carga y poco más. Con respecto al acceso a configuracion, ya vi que era una instancia de ambito local a run(), y me parece bien, puesto que debe ocultarse todo lo relativo a configuracion interna de componentes. La estrategia a seguir, sería meter accesores en el sitio adecuado, para aquellas cosas que se fueran usando. Necesitaría dicha funcionalidad para la fase II de HTE. Un saludo El 17/05/2010 16:19, Cisco escribió:Hola. La idea original fue implementarlo como propones, pero se generaba un código spaguetti muy difícil de mantener y que aporta muy poco, además de que hace mucho más difícil estudiar los errores de configuración. En cuanto a hacer público el objeto de nemesis::Configuration usado para configurar todos los subsistemas no es posible, porque se crea y se destruyen en el mismo método, es decir, se crea, se carga la configuración correspondiente, se establecen los valores y se destruyen el objeto. Si quieres obtener algún valor de la aplicación, seguramente podrás preguntarlo a la instancia concreta sobre la que se aplica el parámetro en cuestión. Un saludo. On May 17, 4:00 pm, Eduardo Ramos Testillano<era...@tid.es>wrote:Hola, En la sdp::Application, veo que hace s un if-else con prioridad sobre el .config del proceso. Si existe dicho archivo, ya no abres el general (esta en el else). Necesitaría que no fuese excluyente, es decir que se "unieran" al igual que ocurre en la plataforma SDP con archivos como el distribuidor.cnf, cuyos parametros pueden ser pisados por los procesos, pero si no existen en aquellos, se toman los del archivo general.Para mantener la prioridad sobre el proceso, simplemente cambiar el if-else por un carga general + carga particular. No se si es posible la carga acumulativa con pisado de parametros previos. De la misma manera, en el sdp::Application::run, tras leer la configuracion haces un if(hasConfiguration) y asignas los valores a los diferentes modulos, algunos de los cuales tienen sus gets para acceder indirectamente a los datos originarios de la instancia configuration. Dicha instancia, creada en el run(), no es accesible hacia fuera. Quizá convendría tener un 'const Configuration &am p; sdp::Application::getConfiguration()' para poder usar ciertos valores desde la aplicación. Entiendo que algunos debieran ser ocultos, en tal caso, en vez de ese get, habría que hacer los gets a nivel de sdp::Application, para los parametros que pudieran ser añadidos en el futuro. Un saludo-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónicoanem...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónicoanemesisrd...@googlegroups.comParatener acceso a más opciones, visita el grupo enhttp://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDown load-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico anemes...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico anemesisrd-1...@googlegroups.comPara tener acceso a más opciones, visita el grupo enhttp://groups.google.com/group/nemesisrd-1x?hl=es. firma.jpg 8KViewDownload--
Primera idea: NemesisRD.sdp y NemesisRD.comm tienen varios valores que
vienen con un valor por defecto y por lo que nadie tendrá que
preocuparse
en el 99% de los casos.
Ahora supón que implementamos el sistema que tu propones y tenemos un
archivo de configuración global con los valores:
AA = 100
BB = 200
CC = 300
DD = 400
y ahora el archivo particular, en el que sólo configuras el nuevo
valor de DD:
DD' = 333
Qué buen sistema!!
Pero ahora imagina que quieres que AA no tenga ningún valor, es decir,
que tome el valor que tenga la plataforma pero como el global
tienes AA=100, ¿cómo indicas que en tu caso particular no quieres que
AA tome ningún valor?, es decir, que quieres que AA se quede con el
valor por defecto que estableza por defecto la plataforma.
La solución más directa es indicar un número mágico!!! ¿-1, -666, 0,
"periquito", ""?
Así que con el sistema que propones una vez que la entrada exista en
la configuración global, dependes de valores mágicos,
lo que viene a indicar que no es una solución-completa, lo que viene a
indicar que no es aconsejable usarlo en una plataforma.
Creo que hay que intentar homogeneizar, pero sólo en las cosas útiles.
De todas formas si sigues necesitando usarlo en tu proceso creo que
dispones de todas las herramientas para solucionar
el problema, sin que esta solución tenga que estar integrada en la
plataforma.
Un saludo.
On May 18, 3:06 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> ya lo se, pero se trata de intentar que actue igual que la otra plataforma para homogeneizar comportamientos de configurabilidad.
> un saludo
Eduardo Ramos Testillano
May 18, 2010, 9:43:52 AM5/18/10
to nemesi...@googlegroups.com
En el 99% de los casos tenemos:
distribuidor.cnf:
INT MAXIMO_NUMERO_FD
1000
INT TIMEOUT_CONNECT_TCP
500
INT TIMEOUT_SEND_TROCEADO
500
Y quiza: <proceso>.cnf:
INT TIMEOUT_CONNECT_TCP
1500
El funcionamiento en plataforma clasica da lugar a un timeout de 1500, un troceado de 500, y un maxFds de 1000.
La configuracion "heredable" no es un cajón de sastre, en el 99% de los casos, todas las variables son utilizadas porque forman parte de la configuracion final del proceso. Por lo tanto, pensar que una variable AA del general, no la quiera usar en el proceso, es improbable y en tal caso, no veo que sea "puñalada de pícaro" es usar un valor mágico "" (nada de periquitos ni gaviolas).
Lo mejor sería que el comportamiento por defecto fuera heredable, y si acaso un proceso necesita que no lo sea, pues podría reimplementarlo como lo tienes actualmente. Y las asignaciones hacia los componentes de la plataforma, quizá no debieran hacerse dentro del run(), para facilitar este tipo de re-implementaciones.
un saludo
distribuidor.cnf:
INT MAXIMO_NUMERO_FD
1000
INT TIMEOUT_CONNECT_TCP
500
INT TIMEOUT_SEND_TROCEADO
500
Y quiza: <proceso>.cnf:
INT TIMEOUT_CONNECT_TCP
1500
El funcionamiento en plataforma clasica da lugar a un timeout de 1500, un troceado de 500, y un maxFds de 1000.
La configuracion "heredable" no es un cajón de sastre, en el 99% de los casos, todas las variables son utilizadas porque forman parte de la configuracion final del proceso. Por lo tanto, pensar que una variable AA del general, no la quiera usar en el proceso, es improbable y en tal caso, no veo que sea "puñalada de pícaro" es usar un valor mágico "" (nada de periquitos ni gaviolas).
Lo mejor sería que el comportamiento por defecto fuera heredable, y si acaso un proceso necesita que no lo sea, pues podría reimplementarlo como lo tienes actualmente. Y las asignaciones hacia los componentes de la plataforma, quizá no debieran hacerse dentro del run(), para facilitar este tipo de re-implementaciones.
un saludo
--
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages