FAQ's - Preguntas más frecuentes

Aquí encontrará toda la documentación online de SaltOS.


Desde el 17 de noviembre del 2014, las API v1 y v2 para acceder a los servicios de Google han dejado de funcionar forzando a todos los desarrolladores a migrar sus códigos a la v3 de la nueva API (https://developers.google.com/api-client-library/php/). En SaltOS, como el resto de aplicaciones, hemos tenido que hacer este cambio y ya vuelve todo a funcionar.

Antiguamente, el acceso al servicio se podía obtener usando el usuario+password de la cuenta del servicio. Actualmente esto ya no funciona así, sino que se debe obtener un token que nos permitirá el acceso futuro al servicio hasta que el usuario revoque el token. Para ello, es necesario crear una key desde la consola de desarrolladores de google developers. Hay 2 tipos: para aplicación online y por lo tanto, estará asociada a un host, o para aplicación instalada, la cual no estará asociada a un host. Este segundo caso es el que nosotros hemos empleado para crear la key de acceso al servicio pues la primera no nos vale.

Actualmente, cuando es necesario que el usuario se autentifique, lo que esta API propone es que redirijamos nuestra página hacia una página de Google donde se deberán seguir 3 pasos:

1) Si no esta autentificado en Google, se le solicita al usuario su email y password de Google.
2) Se le pregunta si desea dar permiso para que la aplicación acceda a sus datos de la aplicación deseada (en el caso de SaltOS, es Google Calendar).
3) Aparecerá una pantalla con una caja de texto que contendrá el token y se le indica al usuario que haga copy-paste de ese código a la aplicación.

Si la key creada tiene asociada un host, el punto 3 es automático, pues se redirige al host pasando por parámetro el token obtenido. Como en nuestro caso hemos creado una key para aplicación instalada, no tiene host y por lo tanto hay que hacer el copy-paste del token hacia SaltOS.

Como podéis ver, es un proceso tedioso para el usuario, y desde SaltOS, hemos programado una solución para ahorrarle todo este proceso extra causado por la falta de un mecanismo de autentificación directo desde la API v3 de Google. El "truco" consiste en hacer los pasos que quiere Google para obtener el token (token1 en adelante) mediante programación.

Este token, debe ser pasado al método authenticate del cliente de google y esto hará que obtengamos el segundo token (token2 en adelante) que será el que podremos usar en las futuras peticiones para acceder al servicio. Como resumen:

1) Si no tenemos el token2, obtener el token1 con el usuario+password y nos autentificamos mediante authenticate. El token2 que usaremos en las futuras autentificaciones lo obtendremos mediante getAccessToken.
2) si ya tenemos el token2, lo usamos para autentificar mediante setAccessToken

Para ello, SaltOS define las siguientes funciones:

function __gcalendar_getattr($html,$attr)

Esta función retorna el valor del primer atributo que encuentra en $html. Por ejemplo: si se pasa en $html un nodo <form> y se pasa en $attr la cadena "method", retornará GET o POST.

function __gcalendar_getnode($html,$name)

Esta función retornará la porción de código $html cuyo tag sea $name. Por ejemplo: si se pasa un formulario html y se pide el nodo <form>, esta función retornará el código html desde <form> hasta </form> con todo lo que contenga este formulario.

function __gcalendar_parse($html)

Esta función retorna en un array estos 3 datos del primer form que hay en $html:

1) El method.
2) El action.
3) Un array con una lista de clave=>valor donde clave es el name de los inputs y valor son los valores de los inputs.

function __gcalendar_request($url,$method="",$values=array(),$cookies=array(),$referer="")

Esta función usa una clase usada en SaltOS (http://www.phpclasses.org/package/3-PHP-HTTP-client-to-access-Web-site-pages.html) que permite hacer peticiones http de forma rápida.

Esta función hace una petición a la $url, usando el $method, enviando las variables del array $values, usando las cookies del array $cookies y usando el referer de $referer. Retorna un array con 3 elementos:

1) El body.
2) Un array con los headers.
3) Un array con las cookies.

function __gcalendar_token1($client,$login,$password) {
    $url=$client->createAuthUrl();
    list($body,$header,$cookies)=__gcalendar_request($url);
    // PROCESS LOGIN PAGE
    $parsed=__gcalendar_parse($body);
    $parsed["inputs"]["Email"]=$login;
    $parsed["inputs"]["Passwd"]=$password;
    $parsed["inputs"]["continue"]=str_replace("&","&",$parsed["inputs"]["continue"]);
    list($body,$header,$cookies)=__gcalendar_request($parsed["action"],$parsed["method"],$parsed["inputs"],$cookies,$url);
    // PROCESS ACCEPT PAGE
    $url=$parsed["action"];
    $parsed=__gcalendar_parse($body);
    $parsed["action"]=str_replace("&","&",$parsed["action"]);
    $parsed["inputs"]["submit_access"]="true";
    list($body,$header,$cookies)=__gcalendar_request($parsed["action"],$parsed["method"],$parsed["inputs"],$cookies,$url);
    // PROCESS TOKEN PAGE
    $html=__gcalendar_getnode($body,"input");
    $token1=__gcalendar_getattr($html,"value");
    return $token1;
}

Esta función es la más interesante de toda la explicación, porque usando las funciones anteriores, consigue obtener el primer token para acceder al servicio de Google Calendar.

Para ello lo que hace es:

1) Obtener la url de autentificación del objeto $client
2) Hacer la primera petición. Esta primera petición obtendrá el código HTML de la página que solicita el email y password para acceder a Google.
3) Del body de resultado de la petición anterior, se obtiene el action, method y la lista de variables del formulario.
4) Se pone valor a los inputs del formulario Email y Passwd
5) Se hace la segunda petición con el action, method y la lista de variables del formulario anterior modificado. Esta segunda petición obtendrá el código HTML de la página que solicita al usuario permiso para acceder a Google Calendar.
6) Del body de resultado de la petición anterior, se obtiene el action, method y la lista de variables del formulario.
7) Se pone "true" al input "submit_access"
8) Se hace la tercera petición con el action, method y la lista de variables del formulario anterior modificado. Esto nos retornará una página html con un input que contendrá el token que necesitamos.
9) Del body de resultado, sólo hay que obtener el nodo <input> y de ese nodo, obtener el valor del atributo "value". Con esto ya tenemos el token.

Notas:

- El punto 1 es directo mediante la API v3 de Google.
- En los puntos 2, 5 y 8 se hacen las 3 peticiones a las páginas que necesitamos (acceso a google, permiso a la aplicación y obtención del token).
- En los puntos 3 y 6 se obtiene el formulario con el action, method y lista de variables.
- En los puntos 4 y 7 se modifica el formulario (emulando la interacción del usuario).
- El punto 9 es procesar la página de resultados.

function __gcalendar_connect($login,$password) {
    $client=new Google_Client();
    $client->setAuthConfigFile("lib/google/saltos.json");
    $client->setRedirectUri("urn:ietf:wg:oauth:2.0:oob");
    $client->addScope("https://www.googleapis.com/auth/calendar");
    $client->setAccessType("offline");
    $token2=execute_query(make_select_query("tbl_gcalendar","token2",make_where_query(array(
        "id_usuario"=>current_user()
    ))));
    if($token2!="") {
        $client->setAccessToken(base64_decode($token2));
        if($client->getAccessToken()) return $client;
    }
    $token1=__gcalendar_token1($client,$login,$password);
    if($token1=="") return null;
    $client->authenticate($token1);
    $token2=$client->getAccessToken();
    if(!$token2) return null;
    $query=make_update_query("tbl_gcalendar",array(
        "token2"=>base64_encode($token2)
    ),"id_usuario='".current_user()."'");
    db_query($query);
    return $client;
}

Esta función es la que nos retornará un objeto con acceso al servicio de Google Calendar.

Lo que hace es crear un objeto Google_Client, establece el fichero que contiene la key creada para el proyecto, establece donde queremos acceder, el tipo de acceso y luego:

1) Si tenemos ya un token2 en la base de datos, lo usamos para autentificarnos mediante setAccessToken. Si este es valido mediante getAccessToken, retornaremos el $client.
2) Si token2 no es valido o no existe, llamaremos a la función anterior (__gcalendar_token1) que mediante el truco anterior nos retornará el token1 de acceso para obtener el token2.
3) Con el token1 anterior, llamaremos a la función authenticate y obtendremos el token2 mediante getAccessToken.
4) Si todo ha ido bien y tenemos ya el token2, lo guardaremos en la base de datos para poder reutilizar el token2 en las futuras peticiones de SaltOS.

Más info:

Para más detalles acerca de lo que he explicado aquí, podéis mirar el código fuente de SaltOS y en concreto, el fichero php/action/gcalendar.php.

Creditos:

Este trabajo de I+D ha sido llevado a cabo por Josep Sanz y Jordi Company.

A continuación se explica rápidamente como instalar SaltOS en un hosting gratuito:
  1. Acceder a cualquiera de los proveedores siguientes (existen otros muchos de iguales prestaciones, condiciones y también gratuitos)
    1. http://www.000webhost.com/
    2. http://www.nixiweb.com/
  2. Crearse un hosting (el primero te permite tener una url personalizada, el segundo no pero te proponen donde hacerlo también gratis)
  3. Acceder al panel de control del hosting que te hayas creado antes
  4. Descargar el nightly de SaltOS (fichero .tgz)
  5. Renombrarlo en el ordenador donde se descargue por .tar.gz
  6. Dependiendo del hosting y idioma, buscar en el panel de control la opción para:
    1. "1-Click Website Restore"
    2. "Importar Sitio"
    3. "Import website"
  7. Esperar mientras se sube el fichero al servidor (puede ser bastante tiempo, depende del ancho de banda que dispongas)
  8. Ir a la web del hosting que habeis hecho en el paso 2 y voila: el programa de instalación de SaltOS te esta esperando.
  9. Pulsar el botón siguiente en todas las pantallas hasta que SaltOS este totalmente instalado.
Notas de los hostings:
  • La lista de hostings anteriores son meramente informativas, no tengo ningún trato de favor con ellos.
  • SaltOS ha estado probado en estos hostings (por eso aparecen aquí)
Notas de la instalación de SaltOS:
  • Si quieres usar un nombre de usuario/clave diferente a admin/admin, mirate el paso 3
  • Si quieres cargar datos de ejemplo, marca la opción correspondiente en el paso 3
  • Los datos del callejero pueden dar problemas y sólo contienen los datos de España.
Desde PHP 5.3.9, se ha añadido una directiva de configuracion max_input_vars que limita el número de variables que pueden llegar por $_GET, $_POST y $_COOKIE. Esto a llevado a que aplicaciones que emplean formularios con muchos inputs tipo checkbox / hidden / text, puedan tener problemas al perder datos en la recepción desde el servidor.

Esta directiva, básicamente, mitiga la posibilidad de ataques de denegación de servicio que utilizan colisiones de hash. Por lo tanto, puede pasar que en algunos hostings exista esta variable y este limitada a su valor por defecto (1000) y no tengamos opción de aumentar el valor. Si esto sucede, se deberá o bien:
  • Replantear la aplicación para no superar el número de variables máximas (algo realmente costoso en algunos casos)
  • Usar la técnica que a continuación voy a describir que solucionará este problema de forma transparente sin necesidad de tocar nada en el lado del servidor.
La técnica consiste en anticiparse al servidor, es decir, si conocemos de antemano la limitación que puede tener el servidor que va a recibir el formulario con las más de N variables, podemos hacer lo siguiente:

1) Desde un php, informar al cliente de el valor que tiene la variable max_input_vars:

<?php
function ini_get_max_input_vars() {
	return '".intval(ini_get("max_input_vars"))."';
}
?>

2) Desde el cliente, antes de enviar el formulario, añadir este código:

<script>
var max_input_vars=ini_get_max_input_vars();
if(max_input_vars>0) {
	var total_input_vars=$("input,select,textarea",jqForm).length;
	if(total_input_vars>max_input_vars) {
		var fix_input_vars=new Array();
		$("input[type=checkbox]:not(:checked):not(:visible)",jqForm).each(function() {
			if(total_input_vars>=max_input_vars) {
				$(this).remove();
				total_input_vars--;
			}
		});
		$("input[type=checkbox]:checked:not(:visible)",jqForm).each(function() {
			if(total_input_vars>=max_input_vars) {
				var temp=$(this).attr("name")+"="+rawurlencode($(this).val());
				fix_input_vars.push(temp);
				$(this).remove();
				total_input_vars--;
			}
		});
		$("input[type=hidden]",jqForm).each(function() {
			if(total_input_vars>=max_input_vars) {
				var temp=$(this).attr("name")+"="+rawurlencode($(this).val());
				fix_input_vars.push(temp);
				$(this).remove();
				total_input_vars--;
			}
		});
		fix_input_vars=base64_encode(utf8_encode(implode("&",fix_input_vars)));
		$(jqForm).append("<input type='hidden' name='fix_input_vars' value='"+fix_input_vars+"'/>");
	}
}
</script>

3) Desde el php que ha de recibir los datos, añadir este código antes de empezar a procesar la petición:

<?php
if(intval(ini_get("max_input_vars"))>0) {
	$temp=getParam("fix_input_vars");
	if($temp!="") {
		$temp=querystring2array(base64_decode($temp));
		if(isset($_GET["fix_input_vars"])) {
			unset($_GET["fix_input_vars"]);
			$_GET=array_merge($_GET,$temp);
		}
		if(isset($_POST["fix_input_vars"])) {
			unset($_POST["fix_input_vars"]);
			$_POST=array_merge($_POST,$temp);
		}
	}
}
?>

Notas:
  • El concepto es:
    • Informar del valor max_input_vars del servidor
    • Desde el cliente, proceder a reducir las variables si es necesario hasta que cumpla la condición que el número de variables sea inferior al máximo.
    • De esta manera, se podrá añadir una variable auxiliar que contendrá a las otras variables embedded
    • Desde la recepción, detectar ese caso y hacer el paso inverso para dejarlo todo tal como tiene que estar
  • En el fragmento de código 2:
  • En el fragmento de código 3:
    • Las funciones getParam y querystring2array son proporcionadas por el proyecto SaltOS (véase el fichero php/strutils.php)
  • Para más info, podeis mirar el código fuente de SaltOS que ya incorpora este trick.
Tras varias transacciones comerciales/empresariales que han llevado a MySQL de un lado a otro, finalmente ahora es propiedad de Oracle (empresa que se dedica a comercializar otros SGBD privativos). Bajo mi punto de vista, estos hechos han llevado al proyecto de software libre MySQL a vivir un deterioro global puesto que este sistema gestor de base de datos (SGBD) actualmente ofrece un rendimiento excesivamente bajo, cosa que se hace latente en SaltOS cuando el sistema tiene un elevado número de datos.

Los tests que empleo para optimizar las consultas de SaltOS usan un paquete de datos predefinido y se ejecutan sobre SQLite y MySQL (los dos SGBD soportados actualmente). Para medir los tiempos de respuesta empleo simplemente los comandos time y wget desde la línea de comandos, de forma que puedo hacerme una idea rápida de la eficiencia de las consultas mientras desarrollo. Lás diferencias entre estos dós sistemas para consultas relacionadas con la aplicación de correo electrónico y dado un mismo juego de datos es de:
  • page=correo&action=list: 289ms (SQLite) vs 1548ms (MySQL)
  • page=correo&action=quickform: 286ms (SQLite) vs 1380ms (MySQL)
Como se puede ver, la diferencia es sustancial: SQLite sólo requiere un 20% aprox. del tiempo que necesita MySQL. Tras revisar y intentar hacer optimizaciones, todas inútiles por cierto, descubrí a MariaDB, un fork del proyecto MySQL, hecho por uno de los autores de MySQL que dejo su trabajo tras entender, sin que nadie le explicara nada, las intenciones que tenia la nueva compañia con MySQL. Instalé rápidamente este reemplazo de MySQL en mi portatil, desde los repositorios del propio proyecto para Fedora 17 y voila, ya tenia a MariaDB corriendo en lugar de MySQL. Mi sorpresa fue sustancial cuando ejecute los tests para la misma aplicación y pude observar que las consultas de MariaDB se ejecutaban con velocidades muy similares a las de SQLite:
  • page=correo&action=list: 288ms (SQLite) vs 413ms (MariaDB)
  • page=correo&action=quickform: 285ms (SQLite) vs 335ms (MariaDB)
Increiblemente, se habian reducido los tiempos de ejecución de MariaDB y sin tocar nada de código. Todo sigue funcionando ok, phpMyAdmin funciona ok, SaltOS funciona ok y RhinOS, también funciona ok sobre MariaDB, el reemplazo realmente libre de MySQL. Para más info del proyecto MariaDB: ¿Como instalar MariaDB en Fedora 17?

El proceso de instalación de MariaDB en fedora 17 es sumamente sencillo, basta seguir estos pasos y voila:

1) Añadir el repositorio de MariaDB

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5/fedora17-amd64
gpgcheck = 1
enabled = 1

2) Ejecutar la siguiente secuencia de comandos:

service mysqld stop
rpm -e --nodeps mysql-libs mysql-client mysql-server
rpm --import http://yum.mariadb.org/RPM-GPG-KEY-MariaDB
yum install MariaDB-server MariaDB-client MariaDB-common MariaDB-compat MariaDB-shared
service mysql start
service httpd restart

3) Si al acceder al phpMyAdmin, sale el error de que no encuentra la extensión mysqli, es porque se esta usando el paquete php-mysql en lugar del php-mysqlnd, y se puede solucionar formalmente haciendo:

rpm -e --nodeps php-mysql
yum install php-mysqlnd
service httpd restart

Notas:
  • No hay que hacer caso de los mensajes de error que aparecen diciendo que no se encuentran algunos ficheros del mysql, pues al instalar MariaDB, se comprueban dependencias y se detectan que hay paquetes que dependian de los paquetes desinstalados a mano.
  • Respecto a los repositorios: existen todos estos repos (en el ejemplo hace referencia a fedora 17 para 64 bits):
    • centos5-amd64
    • centos5-x86
    • centos6-amd64
    • centos6-x86
    • fedora16-amd64
    • fedora16-x86
    • fedora17-amd64
    • fedora17-x86
    • rhel5-amd64
    • rhel5-x86
    • rhel6-amd64
    • rhel6-x86
Actualización (2013-09-07):

Buenas noticias: Fedora 19 ya ha reemplazado MySQL por MariaDB. Como otras muchas distribuciones, al instalar Fedora 19, ya se instala por defecto MariaDB en lugar de MySQL.
SaltOS, se distribuye en 4 paquetes diferentes:
  • PHP: este paquete contiene el programa SaltOS y incluye todo lo necesario para descomprimir y desempaquetar el programa de forma online. Para usar este paquete, descarguese el paquete y dejelo en un directorio de su hosting visible desde Internet. Acceda al fichero de instalación con un navegador y aparecerá la pantalla de "Bienvenida al instalador de SaltOS". Siga los pasos que se le indican y podrá instalar SaltOS en su servidor de forma rápida y automática.
  • RPM: este paquete esta orientado a los usuarios que usen servidores basados en paquetes RPM como RedHat, CentOS, Fedora y otros muchos que han optado por este formato de paquetería. Para instalar este paquete, bastará con ejecutar desde un terminal y con permisos de root el siguiente comando: "rpm -i PAQUETE.RPM". Con esto quedará instalado SaltOS en su sistema. Una vez instalado el paquete, acceda desde un navegador a la url del hosting usando http://www.example.com/saltos/. Esta url dará acceso a la pantalla de bienvenida al instalador de SaltOS. También se creará un acceso directo en el menú de aplicaciones para que pueda acceder de forma cómoda.
  • EXE: este paquete esta orientado a usuarios que quieren probar SaltOS en un ordenador que ejecuta Microsoft Windows (XP, Vista o 7). Para instalar este programa, deberá descargarse el paquete en formato EXE en su ordenador y ejecutarlo. El wizard de instalación que aparece, instalará en su equipo el programa SaltOS. Adicionalmente, también instalará Apache 2 y PHP 5.3 necesarios para poder ejecutar el programa SaltOS. Si su equipo ya tiene instalados estos programas, use otro formato. Una vez instalado el paquete, acceda desde un navegador a la url del hosting usando http://www.example.com/saltos/. Esta url dará acceso a la pantalla de bienvenida al instalador de SaltOS. También se creará un acceso directo en el menú de aplicaciones para que pueda acceder de forma cómoda.
  • TGZ: este paquete contiene el código fuente de SaltOS. Esta orientado a usuarios expertos o para realizar actualizaciones que no requieran del proceso de configuración inicial que proporciona el "Instalador de SaltOS".
SaltOS, crea 2 directorios llamados:
  • code: este directório contiene el código fuente de la aplicación. Cuando se desee actualizar SaltOS, bastará con reemplazar este directorio por el nuevo directorio code del nuevo paquete.
  • user: este directorio contiene la misma estructura que el directorio code usando enlaces simbólicos hacia el directorio code. Esto permite que la aplicación se ejecute en este directorio, se guarden los datos de configuración y de usuario, y que quede separado lógicamente del directorio que contiene el código fuente. Este tipo de directorio que sólo contiene enlaces simbólicos, es lo que se conoce como instancia de la aplicación. Si deseamos tener n instancias para n empresas, bastará con replicar el directorio user pero sólo teniendo 1 copia del código fuente de la aplicación.
Programas externos que usa SaltOS:
  • xsltproc: este programa será necesario sólo si la instalación de PHP no tiene soporte para DomDocument o XsltProcessor. En el resto de casos, no se usará nunca.
  • unoconv: este programa permite a SaltOS convertir cualquier documento a formato PDF para ser visionado con el visor de PDF online.
  • elinks: este comando permite convertir a texto los correos y feeds descargados. Necesario para las aplicaciones de correo y feeds.
  • text2wave: este programa permite convertir de texto a sonido. Será necesario si se desea la prestación de voz.
  • ffmpeg: este programa permite convertir archivos de .wav a .mp3. Será necesario si se desea la prestación de voz.
  • apertium: este programa permite traducir textos a diferentes idiomas. Será necesario si se desea la prestación de traducción online.
  • calc: este programa permite ejecutar operaciones matemáticas. Será necesario si se desea la prestación de calculadora online.
  • aspell: este programa permite corregir textos en diferentes idiomas. Será necesario si se desea la prestación de corrector y traductor online.
  • zcat: este programa únicamente se usa en el proceso de instalación. Si no esta disponible, el instalador tardará mas tiempo en hacer toda la instalación, pero funcionará.
  • sqlite3: este programa únicamente se usa en el proceso de instalación. Si no esta disponible, el instalador tardará mas tiempo en hacer toda la instalación, pero funcionará.
  • mysql: este programa únicamente se usa en el proceso de instalación. Si no esta disponible, el instalador tardará mas tiempo en hacer toda la instalación, pero funcionará.
SaltOS, permite usar 6 drives diferentes para acceder a bases de datos:
  • SQLite (PDO): este driver usa SQLite y es el recomendado por motivos de simplicidad de instalación y por eficiencia en la mayoria de casos. Usa el paquete php-pdo que normalmente incluyen soporte para SQLite y MySQL.
  • MySQL (PDO): este driver es el mismo que el anterior pero usando MySQL en lugar de SQLite.
  • SQLite (extension): este driver permite usar las funciones nativas de sqlite pero normalmente, estan desactualizadas y por ello, no pasan el test del GROUP_CONCAT.
  • MySQL (extension): este driver permite usar las funciones nativas de sqlite y normalmente se suelen usar las versiones más recientes pasando en la mayoria de casos el test del GROUP_CONCAT.
  • SQLite (binary wrapper): este driver, permite en aquellos servidores donde ningún otro driver funcione, subir en binario de sqlite (descargable desde http://www.sqlite.org/download.html) y mediante comunicación por pipes y ficheros de intercambio, ejecutar consultas a una base de datos SQLite permitiendo el buen funcionamiento de SaltOS.
  • MySQL (improved extension): este driver, es una evolución del driver nativo de MySQL. No suele estar instalado en muchos servidores.
El error 500, es un error generado por el servidor cuando se encuentra con una situación de error que no puede resolver de forma automática. Es decir: si no se encuentra un fichero, el error es el 404 (Not found), si no se puede listar un directorio, el error 403 será lanzado (Forbidden). Para los errores que no tienen una definición explícita, se generará el error 500 (Internal error).

Este error, normalmente aparece en Apache:
  • cuando se usan directivas no soportadas en los ficheros .htaccess.
  • en algunos hostings donde las restricciones de seguridad limitan la ejecución de scripts PHP, por ejemplo, sólo si los permisos de escritura estan restringidos al própio usuario (chmod 0644).
Es decir, que cuando aparezca un error 500, debemos probar de desactivar las directivas del .htaccess y comprobar los permisos de los scripts PHP.
Tras algunos meses de estar entre nosotros el nuevo navegador de Microsoft, don Internet Explorer 9, algunos visitantes de saltos.net me informaron de que la web no se veia correctamente usando este navegador.

Tras mirar lo que sucedia, detecte desde los logs del apache que las peticiones de las hojas de estilo que hace Internet Explorer 9, eran respondidas por el própio servidor apache con un error HTTP 406 Not acceptable (No aceptable).

Este portal, esta desarrollado con RhinOS, el cual genera con PHP las hojas de estilo a partir de las plantillas. Esto quiere decir que en realidad, la petición del CSS que se hace, aunque parezca que se hace a un fichero estático .css, sea atendida por un script de PHP que interceptará la petición para atenderla y responder con el contenido del CSS y las cabeceras del content-type correspondientes: "text/css".

Como que el nuevo navegador envía la cabecera "Accept: text/css" únicamente en lugar de lo que todo el mundo hace que es "Accept: text/css; */*", hace que el servidor apache no procese con el php que debería la petición solicitada y al no encontrar la forma de resolverla, envia el error 406.

Para arreglar este problema, basta con añadir en el .htaccess la siguiente linea: "AddType text/css .php". Grácias a esta entrada en el fichero .htaccess, el servidor podrá relacionar las peticiones a un .php con un Accept "text/css", con lo que todo volverá a funcionar como si nada.

Si el servidor tiene desactivada la prestación de usar el fichero .htaccess para sobrecargar esta configuración, RhinOS ofrece otro metodo que consiste en usar una url alternativa que soluciona el problema. Para ello, basta con añadir el tag <!-- INCLUDE PRINT_BASE_IE9CSS --> en la ruta del fichero CSS para que en caso de detectar un cliente con IE9, se publique la nueva url que servirá el contenido sin generar el error 406.

Gracias Microsoft por facilitar las cosas!!!
SaltOS, ha vivido varias transformaciones desde que empezo su desarrollo, tanto a nivel de código como a nivel estético. A continuación, os muestro algunas capturas de pantalla donde se puede ver como empezo todo...

La segunda versión de SaltOS, empezo a usar el azul, pero todavia no conocia jQuery-UI...

Y por fin, conoci el framework jQuery i jQuery-UI, empezando a reescribir el interficie con el estilo gráfico actual y usando AJAX en el 100% de las transacciones.

Espero que el estilo gráfico de SaltOS os guste...
Hace tiempo que uso JQuery-UI para dar aspecto gráfico a mis aplicaciones. Desde los inicios, SaltOS ha incorporado los 24 temas definidos en el ThemeRoller.

Estos temas son prácticos y combinan bien los colores, pero en SaltOS detecté un problema: JQuery-UI define los estilos para las clases Header, Content, Default, Hover, Active, Highlight y Error (entre otros) y al hacer un listado o un menú como en SaltOS, se usan varias clases para hacer las filas pares e impares, para hacer el efecto hover (que yo uso el highlight en lugar de la propia clase hover pues es más visual) o incluso el background de la propia página. Esto hace que algunos temas sean "difíciles" de ver y sólo se acaben usando algunos de los 24 temas.

Este problema no es un problema asociado a JQuery-UI, sino a como SaltOS usa las combinaciones de colores (y hay que ser realista, pues hacer una aplicación con entorno gráfico no es tarea fácil).

La solución ha sido usar un tema como base (Redmond) y programar algo que permita colorizar ese tema (que es con tendencias azules) usando otros colores base y así tener un único tema que sea "bonito" de ver y que el usuario pueda permutar entre varias gamas de colores.

Para ello, investigué como la aplicación ThemeRoller genera los temas (CSS + imágenes) y programé un equivalente del ThemeRoller en SaltOS para colorizar los temas de forma que ahora SaltOS dispone de 18 temas basados en permutaciones de colores del tema Redmond (existen 9 temas sobre blanco y otros 9 temas sobre negro).

Quien quiera ver como funciona el themeRoller de SaltOS, que visite las demos y el que quiera ver como esta programado, que mire en los ficheros themeroller.php y themeroller.xml del código fuente.
Las notificaciones de escritorio es una prestación definido y usado por Google (con sus productor Google Chrome y GMail) que permite mostrar notificaciones integradas en el propio escritorio del usuario cuando sucede un evento.

SaltOS, añade este soporte también para redirigir las notificaciones que aparecen dentro de la aplicación hacia el escritorio del usuario. De esta manera, cuando se recibe un correo nuevo, se descarga un post o simplemente salta una alarma de la agenda, SaltOS mostrará en el escritorio del usuario un mensaje indicando el evento.

Adicionalmente, SaltOS incluye otros mecanismos para avisar a los usuarios como la animación del favicon y las notificaciones por voz, permitiendo al usuario oir los mensajes que aparecen y hasta oir los asuntos de los correos, posts y eventos.

En el caso de Firefox,  existen extensiones que añaden el soporte en el navegador para usar las notificaciones integradas en el escritorio: https://addons.mozilla.org/es-ES/firefox/addon/html-notifications/
SaltOS aparece en la publicación del mes de marzo, número 124, de la revista Todo Linux. El artículo se llama "SaltOS: CRM y ERP opensource", escrito por Arturo Fernandez y nos deja bastante bien.





Introducción:

El Cloud Computing, también llamado computación en la nuve,  es el término empleado para hablar del concepto de disponer de las aplicaciones desde Internet.

Para entender la diferencia entre Cloud Computing y el modelo tradicional, hay que explicar algunas partes de la historia de la informática brevemente:
  • Al principio de la informática, las aplicaciones se ejecutaban en servidores y los usuarios operaban con terminales (también llamados terminales tontos) y no tenían ninguna funcionalidad específica. Se conectaban al servidor mediante Telnet y se operaba mediante terminales de texto.
  • La aparición y evolución de los sistemas operativos, llevo a descentralizar los sistemas informáticos permitiendo disponer de un computador con su sistema operativo y aplicaciones instaladas en él (este es el modelo que se emplea actualmente en la gran mayoría de casos). Este modelo tiene la desventaja que para grandes infraestructuras empresariales, el coste de mantenimiento es altamente costoso y complejo.
Explicación:

El Cloud Computing, es la mezcla de los dos modelos. Actualmente los usuarios disponen de computadores con sistemas operativos y ciertas funcionalidades integradas en ellos. El Cloud Computing quiere volver a emplear el modelo basado en cliente-servidor donde las aplicaciones (código + datos) estén centralizados y ubicados en un servidor o conjunto de servidores y el cliente, pueda trabajar con una aplicación tipo cliente sencillo (que lo habitual será un navegador web).

La tecnología, además permite solucionar actualmente ciertos problemas de el primer modelo (servidor centralizado) como la gestión de los recursos. Hasta ahora, las empresas, dedicaban un numero finito y acotado de recursos para una aplicación o servicio, pero si la carga computacional excedía esta previsión, se obtenían denegaciones de servicio por sobrecarga. El concepto Cloud Computing, además incluye el aprovisionamiento dinámico de recursos (CPU, memória RAM, disco duro, periféricos, etc...). De esta manera, se garantiza que una aplicación gastará únicamente lo que necesite y en caso de sobrecarga, se activarán nuevas máquinas para dar salida computacional a las necesidades de ese instante de tiempo.

Esto acaba siendo un beneficio para cualquier usuario pues aporta las siguientes mejoras:
  • Ventajas de la centralización: es sencillo hacer copias de seguridad (normalmente las hará el propio proveedor del servicio).
  • Acceso universal: desde cualquier lugar, se podrá trabajar con las aplicaciones deseadas si disponemos de acceso a Internet.
  • Bajo coste de mantenimiento: una actualización se aplica a todos los usuarios de forma rápida y segura sin necesidad de ir equipo por equipo aplicando parches.
Pero también tiene desventajas:
  • Dependencia del proveedor: si el proveedor nos corta el servicio, nos quedamos sin aplicación.
  • En algunos casos, los datos estarán en poder de terceros y nosotros tendremos la dependencia tecnológica de su aplicación y de los datos (es importante poder exportar los datos en un formato estandarizado para poder cambiar de aplicación o disponer de las fuentes de la aplicación que los ha creado).
Conclusión:

Como conclusión, decir que la tendencia natural del mercado es hacia las aplicaciones en la nuve y empleando tecnologías RIA (Rich Internet Applications). Por ello  SaltOS fue diseñado como RIA para la nuve o más comúnmente llamado Rich Internet Application & Cloud Computing.
Introducción:

POP (Post Office Protocol) y IMAP (Internet Message Access Protocol), son dos protocolos que permiten el acceso a las carpetas del correo entrante de un servidor de correo (no permiten el envío de correo). Nos podemos referir a POP como POP3 (última versión) y IMAP como IMAP4. Estos protocolos son soportados por la mayoría de servidores de correo existentes.

Ventajas e inconveniente de POP3 vs IMAP4:
  • El número de transacciones es bajo, con lo que es eficiente.
  • No hay correlación entre la lista de correos con los identificadores que se emplean, con lo que cada vez que se establece la conexión, se debe descargar la lista de correos con sus identificadores (UIDL's).
  • Permite el trabajo offline, pues el cliente se descarga los datos y se gestionan desde la propia aplicación cliente.
  • Sólo puede gestionar una única carpeta.
  • La gestión es simple, con lo que no puede marcar un correo en el servidor como leído, es tarea del cliente hacer esa gestión.
Ventajas e inconveniente de IMAP4 vs POP3:
  • El número de transacciones es alto, con lo que requiere mayor conectividad entre cliente y servidor.
  • Permite el trabajo offline pero debe conectarse al servidor para realizar actualizaciones en los estados de los correos almacenados (si se lee un correo en el cliente, se indicará en el servidor que ese correo ya esta leído con lo que otro cliente que use el mismo protocolo, verá que ya se ha leído ese correo y no lo marcará como nuevo)
  • Puede gestionar varias carpetas (sólo existe una carpeta de entrada, pero el usuario puede mover el correo a otra carpeta en el propio servidor).
  • La gestión es más compleja, puesto que cada acción que hace el cliente, debe notificarse al servidor para mantener la coherencia (si se lee el correo desde un cliente, el resto de clientes deben actualizar su estado a leído, aunque depende de la complejidad que implemente el propio cliente).
Conclusión

Los dos protocolos dan el servicio básico para la gestión del correo electrónico. Hay que tener en cuenta si se desea un sistema distribuido de clientes o un sistema unificado de clientes. Por ejemplo, si se emplean varios clientes de correo como Evolution y Thunderbird, es interesante emplear IMAP4. Si por el contrario, se decide leer el correo únicamente empleando una aplicación como SaltOS, entonces POP3 es una buena elección, pues no es necesaria la gestión en el servidor de los correos leídos, carpetas y demás prestaciones que aporta IMAP4 ya que SaltOS integra estas prestaciones en el propio cliente de correo.
MariaDB (el nuevo MySQL realmente libre) es uno de los sistemas gestores de bases de datos relacionales más conocidos en el mundo del software libre (de hecho, se emplea LAMP para indicar Linux + Apache + MariaDB (MySQL) + PHP).

SQLite3 es otro sistema gestor de bases de datos pero orientado a las aplicaciones empotradas, usado en aplicaciones tan conocidas como Firefox, Thunderbird, Android, y así hasta completar una larga lista de programas que lo usan.

Las diferencias, radican básicamente en que MariaDB (MySQL) es un servidor que atiende peticiones que se le realizan a un puerto usando una conexión TCP/IP tradicional, mientras que SQLite3 es más que un servidor, una librería soportada por la gran mayoría de lenguajes de programación y que permiten acceder a un fichero local como si de una base de datos se tratara.

Así que como resumen se puede decir que SQLite3 es una base de datos orientada a fichero mientras que MariaDB (MySQL) esta orientado como servicio.

El problema que suelen tener las bases de datos orientadas a fichero es la concurrencia (controlar cuando uno escribe que otro no lo haga para mantener la integridad del propio fichero).

En SaltOS, está solucionado usando semáforos POSIX que permiten este tipo de control y así, evitar el acceso concurrente de 2 threads del servidor, por ejemplo, al mismo tiempo para escribir.

Las API's de SaltOS definen 2 funciones llamadas semaphore_acquire y semaphore_release, que internamente emplean la función de PHP llamada flock que permite precisamente controlar el bloqueo de un fichero que es definido como semáforo.

Con este mecanismo, se evita la concurrencia sobre las bases de datos SQLite3 garantizando así la integridad del fichero, y por lo tanto, de los datos.
SaltOS es un juego de palabras entre el azucar y la sal.
 
Cuando se creo la empresa, en el año 2007, se buscó alguna solución existente para la gestión empresarial. Una de las premisas fue el uso de tecnologías emergentes y que fuera soportada por la mayoría de empresas de hosting como es el caso de PHP.
 
Por aquel entonces, sólo encontramos un software llamado SugarOS (actualmente se llama SugarCRM) y tras probarlo, decidimos emprender la aventura de crear una aplicación nueva que permitiera aplicar evolutivos de forma rápida.
 
Dado que la última opción que revisamos fue SugarOS y "sugar" es "azúcar" en inglés, decidimos darle la vuelta y construimos el nombre con "Salt" y "OS" dando lugar a la palabra SaltOS, que además, en castellano tiene correspondencia con una palabra existente.
 
Es típico emplear la terminación OS en los proyectos de sistemas operativos aunque en nuestro caso, la terminación OS quiere decir Open Source.
Sí. Los términos de la licencia GPL-3.0 establecen que con cualquier modificación que se distribuya al público, se debe proporcionar también el código fuente de la misma.
No. Si utiliza el programa con sus modificaciones en un entorno privado o en su propia empresa, no está obligado a compartirlo con nadie.
De momento no existe ningún programa de Partners y el soporte técnico se obtiene preguntando al foro.
Las cualidades que hacen de SaltOS como un buen candidato para desarrollar CMS/ERPs profesionales son:
  • Empleo de tecnologías emergentes como PHP, XML, XSLT y Javascript.
  • Interfaz simple y rápida.
  • Facilidad de configuración y parametrización
  • Simplicidad en el modelo de datos que emplea
  • Pseudo-lenguaje fácil basado en tags XML
  • Rapidez y facilidad en la creación de nuevas aplicaciones
Además de todo lo anterior, SaltOS dispone de una comunidad que hace que evolucione constantemente.
Este proyecto nació como un desarrollo interno para dar solución a un requerimiento propio: la gestión de WS3.

Tras buscar en numerosos proyectos ya existentes, encontramos que existían varias soluciones pero todos tenían inconvenientes:
  • Usaban servidores basados en tecnologías Java, lo cual hacia complejo y caro encontrar empresas de hosting que dieran esos servicios.
  • La codificación no era por capas, teniendo código HTML, CSS y PHP mezclado en un mismo fragmento de código.
Los hechos, nos llevaron a desarrollar una aplicación simple que emplea tecnología PHP, XML, XSLT y Javascript dando lugar a SaltOS.
No, las versiones liberadas no pueden sufrir ningún cambio en sus condiciones de uso.
No, los programas al ser Software Libre no están sujetas a ninguna cuota o royalty para poder utilizarlos.
Estas son las principales ventajas del software libre:
  • No debe pagar ninguna licencia, cuota o royalty. Esto implica un importante ahorro en la adquisición y mantenimiento.
  • Tiene total libertad de uso y distribución.
  • Tiene a su disposición el código de fuente, con lo cual podrá modificar la aplicación y adaptarla a sus necesidades. Esto también le garantiza la independencia de proveedor.
La empresa Wide Spectrum Software Solutions S.L. creia firmemente en la filosofía del Software Libre y quiso aportar su grano de arena a la comunidad.

Actualmente, esta empresa ha cesado su actividad y Josep Sanz Campderrós, co-fundador de la misma, continua por su cuenta con el desarrollo de estos dos proyectos de software libre liberados bajo la licencia GPL-3.0

Cualquier persona o empresa que quiera utilizar estos programas, puede hacerlo sin necesidad de pagar ninguna licencia, ni inicial ni anual. Esto significa un importe ahorro económico que puede ser invertido en la personalización y adaptación del producto.