Explicación de como utilizar OpenOffice instalado en el servidor web, desde PHP, y así poder convertir documentos de oficina a formatos visualizables por el navegador, o al formato que queramos, es una forma de salvar el obstáculo de los formatos cerrados, poco documentados, o a los que PHP no da soporte. Se dan un par de ejemplos, como pasar de ods a xhtml, y extraer una presentación en forma de imágenes JPEG.
#4 No es muy congruente que hables de portabilidad en su acepción referente a arquitectura, cuando estamos hablando de sistemas.
Cuando te digo portabilidad, es que meter una macro en el OOo y ejecutarla con shell_exec, se puede hacer en 1 minuto, por cualquiera, y en cualquier sistema operativo (¿estás insinuando que shell_exec es solo para un sistema concreto, por ejemplo, Unix? )
Sin embargo, un binding a PHP, tal como describes, no es un proceso tan sencillo, yo puedo resumir en 3 pasos el uso con macros:
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
Todos los sistemas operativos disponen de llamadas al sistema para ejecutar OOo con parametros, en todos los sistemas operativos en los que se soporta OOo, se soporta el uso de parametros.
Entonces, me estás diciendo que mi explicación es poco congruente, solo por que yo hago un matiz para Unix, donde existe un problema concreto, (las X) y lo soluciono con Xvfb, cuando toda la explicación es totalmente compatible con cualquier sistema?
Si la gente usa COM en Office de microsoft, es por lo haces en 1 minuto, y la solución análoga que tu planteas es:
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Eso, a mi modo de verlo, es matar moscas a cañonazos.
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Yo por lo general, cuando hablamos del mundo web, e incluimos el "te haces un binding en c++" ya desecho la propuesta, por que si estás ofreciendo software libre a terceros, vas a tener que dar compilables, con configures etc, solo para instalar una web.
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
#6 no voy a citarte "punto-a-punto" tu post como tu has echo con el mio, por que eso SI es demagogia.
Sin embargo, una puntualización:
También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
A no? que me lo impide? no veo el problema aquí, solo tendrías que poner el PHP que hace de front-end en la máquina gorda, y consumirlo desde las máquinas front-end.
No quiero decir que la solución con UNO no sea válida, solo quiero decir, que en muchos casos, no es la mejor, debido a que requiere códigos específicos en C++, que requieren ser compilados en la máquina objetivo, lo cual ya tiene unas implicaciones de por si.
Acerca de mi soltura con el C++, no tengo ningún problema, como ya he dicho, conozco el sdk de OOo.
Por cierto, tu link al código de SergeM no es óptimo, no es compilable tal cual, y el mismo dice que ya dará mas información.
Para un código listo para usar (aunque habría que mejorar algunos aspectos):
No me he puesto a la defensiva, la palabra escrita no tiene tono, solo estaba aclarando mi punto de vista acerca de algunos comentarios que has echo, pero vaya, que era de forma totalmente constructiva.
#2 yo también conozco UDK (UNO) y he trabajado con el en C++, sin embargo, veo muy exagerado crear un binding para comunicarte con OpenOffice desde PHP, no olvides que PHP tiene api para com, pero no para UNO.
Crear un código PHP para comunicarse con UNO en pure-php es un proyecto de una envergadura MUY considerable, yo considero que técnicamente es cierto que usar UDK sería lo mas parecido a COM, pero en cuestiones de facilidad, quien está acostumbrado a COM de Office, esto lo mas cercano, no tiene pies ni cabeza que para hacer una web, tengas que implementarte bindings en C++, aparte de la perdida de portabilidad que ello conlleva.
#1 No exactamente, porque lo que hace es ejecutar soffice cada vez que hay que leer algo. Si quieres usarlo como con el componente COM de Office, tienes que hacerlo a través de UDK (http://udk.openoffice.org), al que se puede acceder desde C++, Python, Java o como componente COM. La "forma correcta" (tm) de hacer lo mismo que en el artículo sería trabajar con el componente de UDK desde PHP, bien haciendo un pequeño código en C++ y luego hacer el binding a PHP (con SWIG, por ejemplo) o "hablando" el protocolo de UNO desde PHP (mucho más trabajo). Además, es más rápido, puesto que sólo es necesaria una instancia de OOo escuchando en un puerto en localhost, a la que se conecta tu código PHP (o lo que sea). Yo he trabajado con UDK en Java, Python y C++ (haciendo un binding para Ruby) y la verdad es que la documentación es bastante amplia, aunque no siempre bien organizada.
#3 Que digas que pierdes portabilidad si lo haces en C++, mientras que en el artículo ejecutas shell_exec y preparas todo el entorno para Unix no es muy congruente. De todas formas, si has trabajado con el UDK desde C++, no deberías tener demasiados problemas. La API es bastante flexible y la documentación amplia, como ya te he dicho. Si usas sólo funciones de OOo tienes la portabilidad garantizada, además si necesitas algo muy concreto (por ejemplo, una función que convierta un documento de texto de cualquier formato a otro), se puede encapsular en una única función y hacer el binding a PHP con SWIG de esa sola función (el binding son 5 minutos). Es más, puedes seguir con las macros y pasárselas al binding como parámetro, con lo que el código es aún más pequeño. Aquí tienes un ejemplo de cómo llamar a una macro desde una función escrita en C++: http://www.oooforum.org/forum/viewtopic.phtml?t=13712
#5 No es muy congruente que hables de portabilidad en su acepción referente a arquitectura, cuando estamos hablando de sistemas.
Creo que no te he entendido, debo estar un poco lento.
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Creo que has sido un poco parcial en estas dos listas que has hecho (todos lo somos :-)), porque con tu solución no has contado con que también que hay que desarrollar las macros y que la parte de conectar a OOo ya viene incluida en el binding. Además de que, el código ya está desarrollado, mira el enlace que he puesto. Por cierto, el código de SWIG es tan complicado como escribir esto:
%module ooophp
%#include "ooophp.h"
%">
%include "ooophp.h"
Eso, a mi modo de verlo, es matar moscas a cañonazos.
Depende de la soltura que tengas en C o C++, a mí me parece una solución válida para hacer una tarea muy muy muy concreta (por favor, no insinues lo de hacer toda la web en C++), muy delimitada en funcionalidades y que puede proporcionarte mucho beneficios. Además de que ya está hecho
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
Ejem, creo que esto sobraba Creo que estarás de acuedo conmigo en que es un poco demagógico.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Pues no, CORBA no es la mejor solución siempre, dependerá siempre del caso. Por otra parte, desarrollar un escritorio web y proporcionar herramientas para convertir formatos, no es un problema cotidiano
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
Pero lo que has escrito no es como COM (CORBA sería COM en este caso), puesto que no estás trabajando con los componentes de UNO. En ningún momento he dicho que esté mal lo que has hecho, si a ti te funciona perfecto, pero hay otras formas de hacerlo más limpias.
Un problema que te puede surgir con tu solución es que si sucede algún error, no sabes qué ha pasado y no podrás informar al usuario. Otro será que si nadie está ejecutando OOo, la próxima vez que alguien haga una petición se cargará todo en memoria. También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
Bueno, si quieres podemos seguir la conversación por e-mail, o continuarla en menéame
#7 creo que tu definición de demagogia no se ajusta a la que tengo yo, en fin. Citar los puntos de tu mensaje es más una cuestión de estilo y claridad. Podría haber respondido directamente a todo el mensaje sin estructurarlo, haciendo que fuera más complicado responder, pero por respeto (tanto a ti, como a los demás) he creído que así sería más fácil mantener la discusión. Si piensas que es demagogia, las discusiones técnicas son todas demagogia ("Internet is for demagogy" :-)) dado que siempre se cita a quien se responde. Si te tengo que ser sincero, creo que te has puesto a la defensiva cuando no hacía falta, se puede tener una discusión técnica sin que las varias partes estén de acuerdo: no pasa nada, es beneficioso.
La solución que propones para distribuir la carga de OOo es curiosa, yo no sería partidario puesto que habría que añadir varias capas más que se pueden evitar usando algo más pequeño (y que ya está hecho, es lo más importante). Pero ¡ojo! no digo que sea errónea, sólo que yo no la usaría. Los otros problemas que he comentado, ¿habría alguna manera de gestionarlos con tu solución? A mí no se me ocurre (lo máximo que se me ocurre es comprobar los códigos de retorno), pero si a ti sí, me gustaría leerlas. Si he propuesto lo de PHP+C++ es porque no se me occure la manera de arreglar lo otro con tu solución.
Mi link al código de SergeM incluye un enlace al código correcto (el que tú has puesto), apunté a la discusión original para saber de dónde salía, por si tenías curiosidad.
Por cierto, cuando he hablado de tener soltura con C++, en ningún momento he dudado de tus capacidades. Simplemente es que si cada día tienes que trabajar con este lenguaje y te tienes que pelear con él, al final hasta acabas cogiéndole cariño (no demasiado, eso sí) y no se te hace tan complicado usarlo.
#8 si cambias el tema, las conclusiones no son las mismas (falacia del hombre de paja, que diría alguno). Y fíjate, que he dicho que lo que hacéis no es algo cotidiano, hacéis una gran labor con el eyeOS. ¿Era necesario ponerse a la defensiva?
Comentarios
#4 No es muy congruente que hables de portabilidad en su acepción referente a arquitectura, cuando estamos hablando de sistemas.
Cuando te digo portabilidad, es que meter una macro en el OOo y ejecutarla con shell_exec, se puede hacer en 1 minuto, por cualquiera, y en cualquier sistema operativo (¿estás insinuando que shell_exec es solo para un sistema concreto, por ejemplo, Unix? )
Sin embargo, un binding a PHP, tal como describes, no es un proceso tan sencillo, yo puedo resumir en 3 pasos el uso con macros:
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
Todos los sistemas operativos disponen de llamadas al sistema para ejecutar OOo con parametros, en todos los sistemas operativos en los que se soporta OOo, se soporta el uso de parametros.
Entonces, me estás diciendo que mi explicación es poco congruente, solo por que yo hago un matiz para Unix, donde existe un problema concreto, (las X) y lo soluciono con Xvfb, cuando toda la explicación es totalmente compatible con cualquier sistema?
Si la gente usa COM en Office de microsoft, es por lo haces en 1 minuto, y la solución análoga que tu planteas es:
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Eso, a mi modo de verlo, es matar moscas a cañonazos.
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Yo por lo general, cuando hablamos del mundo web, e incluimos el "te haces un binding en c++" ya desecho la propuesta, por que si estás ofreciendo software libre a terceros, vas a tener que dar compilables, con configures etc, solo para instalar una web.
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
#6 no voy a citarte "punto-a-punto" tu post como tu has echo con el mio, por que eso SI es demagogia.
Sin embargo, una puntualización:
También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
A no? que me lo impide? no veo el problema aquí, solo tendrías que poner el PHP que hace de front-end en la máquina gorda, y consumirlo desde las máquinas front-end.
No quiero decir que la solución con UNO no sea válida, solo quiero decir, que en muchos casos, no es la mejor, debido a que requiere códigos específicos en C++, que requieren ser compilados en la máquina objetivo, lo cual ya tiene unas implicaciones de por si.
Acerca de mi soltura con el C++, no tengo ningún problema, como ya he dicho, conozco el sdk de OOo.
Por cierto, tu link al código de SergeM no es óptimo, no es compilable tal cual, y el mismo dice que ya dará mas información.
Para un código listo para usar (aunque habría que mejorar algunos aspectos):
http://www.oooforum.org/forum/viewtopic.phtml?t=27453&highlight=
Por cierto: Por otra parte, desarrollar un escritorio web y proporcionar herramientas para convertir formatos, no es un problema cotidiano
Eso no, pero lidiar con formatos de archivo, si.
No me he puesto a la defensiva, la palabra escrita no tiene tono, solo estaba aclarando mi punto de vista acerca de algunos comentarios que has echo, pero vaya, que era de forma totalmente constructiva.
Esto vendría a ser la analogía en el software libre, al uso de Office de Microsoft a través de COM http://es2.php.net/com
#2 yo también conozco UDK (UNO) y he trabajado con el en C++, sin embargo, veo muy exagerado crear un binding para comunicarte con OpenOffice desde PHP, no olvides que PHP tiene api para com, pero no para UNO.
Crear un código PHP para comunicarse con UNO en pure-php es un proyecto de una envergadura MUY considerable, yo considero que técnicamente es cierto que usar UDK sería lo mas parecido a COM, pero en cuestiones de facilidad, quien está acostumbrado a COM de Office, esto lo mas cercano, no tiene pies ni cabeza que para hacer una web, tengas que implementarte bindings en C++, aparte de la perdida de portabilidad que ello conlleva.
#1 No exactamente, porque lo que hace es ejecutar soffice cada vez que hay que leer algo. Si quieres usarlo como con el componente COM de Office, tienes que hacerlo a través de UDK (http://udk.openoffice.org), al que se puede acceder desde C++, Python, Java o como componente COM. La "forma correcta" (tm) de hacer lo mismo que en el artículo sería trabajar con el componente de UDK desde PHP, bien haciendo un pequeño código en C++ y luego hacer el binding a PHP (con SWIG, por ejemplo) o "hablando" el protocolo de UNO desde PHP (mucho más trabajo). Además, es más rápido, puesto que sólo es necesaria una instancia de OOo escuchando en un puerto en localhost, a la que se conecta tu código PHP (o lo que sea). Yo he trabajado con UDK en Java, Python y C++ (haciendo un binding para Ruby) y la verdad es que la documentación es bastante amplia, aunque no siempre bien organizada.
#3 Que digas que pierdes portabilidad si lo haces en C++, mientras que en el artículo ejecutas shell_exec y preparas todo el entorno para Unix no es muy congruente. De todas formas, si has trabajado con el UDK desde C++, no deberías tener demasiados problemas. La API es bastante flexible y la documentación amplia, como ya te he dicho. Si usas sólo funciones de OOo tienes la portabilidad garantizada, además si necesitas algo muy concreto (por ejemplo, una función que convierta un documento de texto de cualquier formato a otro), se puede encapsular en una única función y hacer el binding a PHP con SWIG de esa sola función (el binding son 5 minutos). Es más, puedes seguir con las macros y pasárselas al binding como parámetro, con lo que el código es aún más pequeño. Aquí tienes un ejemplo de cómo llamar a una macro desde una función escrita en C++: http://www.oooforum.org/forum/viewtopic.phtml?t=13712
#5 No es muy congruente que hables de portabilidad en su acepción referente a arquitectura, cuando estamos hablando de sistemas.
Creo que no te he entendido, debo estar un poco lento.
1. instala OOo
2. copia la macro al directorio Tools
3. ejecútala
1. desarrollar un código en C++
2. hacer un binding con swig
3. iniciar el servicio UNO en OOo (startserver)
4. conectar con el usando el binding
Creo que has sido un poco parcial en estas dos listas que has hecho (todos lo somos :-)), porque con tu solución no has contado con que también que hay que desarrollar las macros y que la parte de conectar a OOo ya viene incluida en el binding. Además de que, el código ya está desarrollado, mira el enlace que he puesto. Por cierto, el código de SWIG es tan complicado como escribir esto:
%module ooophp
%#include "ooophp.h"
%">
%include "ooophp.h"
Eso, a mi modo de verlo, es matar moscas a cañonazos.
Depende de la soltura que tengas en C o C++, a mí me parece una solución válida para hacer una tarea muy muy muy concreta (por favor, no insinues lo de hacer toda la web en C++), muy delimitada en funcionalidades y que puede proporcionarte mucho beneficios. Además de que ya está hecho
También podríamos crear un sistema operativo que no cargase nada excepto el PHP, el binding, y lo que necesite el OOo y echo para el hardware de nuestro servidor, ya verías que rápido iría, pero obviamente, no tiene sentido.
Ejem, creo que esto sobraba Creo que estarás de acuedo conmigo en que es un poco demagógico.
A lo que me vengo a referir, es que las soluciones desproporcionadas a problemas cotidianos, no son siempre la mejor idea, tenemos el ejemplo de corba vs xml-rpc, y finalmente, xml-rpc está muchísimo mas extendido (con web services) o incluso rmi (remote method invocation), con java, sin embargo, la mejor solución (técnicamente) es corba.
Pues no, CORBA no es la mejor solución siempre, dependerá siempre del caso. Por otra parte, desarrollar un escritorio web y proporcionar herramientas para convertir formatos, no es un problema cotidiano
Me reitero, la gente no usa COM por que sea lo mas correcto, sino por que es lo mas sencillo.
Pero lo que has escrito no es como COM (CORBA sería COM en este caso), puesto que no estás trabajando con los componentes de UNO. En ningún momento he dicho que esté mal lo que has hecho, si a ti te funciona perfecto, pero hay otras formas de hacerlo más limpias.
Un problema que te puede surgir con tu solución es que si sucede algún error, no sabes qué ha pasado y no podrás informar al usuario. Otro será que si nadie está ejecutando OOo, la próxima vez que alguien haga una petición se cargará todo en memoria. También está el problema de que, si lo deseas, no podrás poner OOo en una máquina "gorda" (o varias), y varios servidores front-end haciéndole(s) peticiones, tendrás que instalar y configurar OOo+Xfvb en cada máquina nueva, añadiendo más carga a los administradores.
Bueno, si quieres podemos seguir la conversación por e-mail, o continuarla en menéame
#7 creo que tu definición de demagogia no se ajusta a la que tengo yo, en fin. Citar los puntos de tu mensaje es más una cuestión de estilo y claridad. Podría haber respondido directamente a todo el mensaje sin estructurarlo, haciendo que fuera más complicado responder, pero por respeto (tanto a ti, como a los demás) he creído que así sería más fácil mantener la discusión. Si piensas que es demagogia, las discusiones técnicas son todas demagogia ("Internet is for demagogy" :-)) dado que siempre se cita a quien se responde. Si te tengo que ser sincero, creo que te has puesto a la defensiva cuando no hacía falta, se puede tener una discusión técnica sin que las varias partes estén de acuerdo: no pasa nada, es beneficioso.
La solución que propones para distribuir la carga de OOo es curiosa, yo no sería partidario puesto que habría que añadir varias capas más que se pueden evitar usando algo más pequeño (y que ya está hecho, es lo más importante). Pero ¡ojo! no digo que sea errónea, sólo que yo no la usaría. Los otros problemas que he comentado, ¿habría alguna manera de gestionarlos con tu solución? A mí no se me ocurre (lo máximo que se me ocurre es comprobar los códigos de retorno), pero si a ti sí, me gustaría leerlas. Si he propuesto lo de PHP+C++ es porque no se me occure la manera de arreglar lo otro con tu solución.
Mi link al código de SergeM incluye un enlace al código correcto (el que tú has puesto), apunté a la discusión original para saber de dónde salía, por si tenías curiosidad.
Por cierto, cuando he hablado de tener soltura con C++, en ningún momento he dudado de tus capacidades. Simplemente es que si cada día tienes que trabajar con este lenguaje y te tienes que pelear con él, al final hasta acabas cogiéndole cariño (no demasiado, eso sí) y no se te hace tan complicado usarlo.
#8 si cambias el tema, las conclusiones no son las mismas (falacia del hombre de paja, que diría alguno). Y fíjate, que he dicho que lo que hacéis no es algo cotidiano, hacéis una gran labor con el eyeOS. ¿Era necesario ponerse a la defensiva?