CodeIgniter es uno de los frameworks PHP de los que más se habla últimamente, a mà personalmente me gusta bastante, aunque hay algunas cosas que no son como me gustarÃa.
Una de ellas es la estructura de las URLs, las URLs siguen el formato:
http://dominio/controlador/metodo/parametro/parametro/...
El controlador es la clase que se encarga de hacer las operaciones y el método es el método de la clase que realiza una función concreta.
Por ejemplo si tenemos una tienda online, podemos tener un controlador para productos y un método que sea editar, con el que se podrá modificar las caracterÃsticas del producto. La url serÃa la siguiente:
http://tienda.com/articulo/editar/cafetera
Con esta url podemos editar un artÃculo llamado cafetera y además es bastante entendible. Pero, ¿qué pasa si queremos mostrar el artÃculo cafetera?, pues que la url deberÃa ser la siguiente:
http://tienda.com/articulo/ver/cafetera
Pero lo de ver no queda demasiado bien y queda mejor si es directamente:
http://tienda.com/articulo/cafetera
El problema nos lo encontramos cuando queremos usar una URL que no indique el método y si un parámetro. Si no usamos ni método ni parámetro, CodeIgniter toma por defecto el método index, pero si no usamos método y si parámetro, CodeIgniter no es capaz de saber que lo que mandamos es un parámetro, por lo que hay que usar el Apache para que siga la estructura de CodeIgniter.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^articulo/(.+)$ index.php/articulo/ver/$1 [L]
RewriteCond $1 !^(index\.php|favicon\.ico)
RewriteRule ^(.*)$ index.php/$1 [L]
Hay que tener en cuenta que este ejemplo es válido únicamente si solo se va a usar siempre dos segmentos en la url, uno para el controlador y otro para el parámetro.
La segunda parte y el uso de index.php es debido a que CodeIgniter usa este script para gestionar toda la aplicación, y para que no aparezca, debemos redireccionarlo todo a index.php, menos los ficheros que existen como el favicon, el robot.txt, etc.
Yo he usado Wildfire (la versión previa de Openfire) para dar soporte a mensajerÃa interna de una empresa con 200/300 usuarios. Además se que la última versión de Openfire está por implementarse en otra empresa para mensajerÃa interna con casi 1000 usuarios y, usando un plugin, también dar soporte a un webchat en el callcenter de dicha empresa.
Gracias, Martin, por lo que dices parece que el rendimiento de Openfire va bien, a mi me han hablado un poco mal de él, por ser Java, aunque yo he trabajado mucho en Java y no he tenido problemas
Saludos
Openfire no está mal. Muy sencillo de instalar y configurar. Una interfaz web bastante completa y muchos plugins, para las pasarelas, webchat, bla bla… Lo malo es que es puro Java y consume demasiados recursos!