Casi todas las aplicaciones en cloud permiten trabajar incluso cuando se pierde la conexión, la posibilidad de que vClient trabaje offline es una característica que sin duda alguna hará nuestras aplicaciones más potentes.
He creado una idea al respecto, espero que os parezca interesante:
No entiendo tu idea (me confundió aun mas tu mención del vClient para Android en la idea), ¿cual sería la diferencia entre lo que propones y un vServer en local?
¿No te estarás refiriendo a la replicación y al hot swap?, porque por si acaso, la idea de replicación ya existe, y ha estado siempre entre las mas votadas. Esta es la idea http://velneo.zendesk.com/entries/21627556-Auto-replicaci%C3%B3n-de-instancias-de-datos
Cribera, no tiene nada que ver con la idea que comentas, ni siquiera se le parece, para trabajar offline no es preciso replicar ninguna base de datos, imagina que tienes un TPV ejecutandose desde la nube, añades productos creas el ticket, pero en un momento dado se pierde la conexión de Internet, no pasa nada vClient sigue dando de alta los tiquets y cuando se recupera la conexión, actualiza los nuevos registros creados fuera de linea.
@Bitcodesoft, cuando dices “se pierde la conexión de Internet, no pasa nada vClient sigue dando de alta los tiquets”
Te pregunto, ¿donde crees que va a ‘seguir dando de alta los tiquets’?, ¿acaso no ba a ser en una estructura paralela? sea que estén definidas las tablas en disco o memoria, ¿no siguen siendo tablas, relaciones, constraints y triggers?
Porque con cualquier ABM que se haga offline, tiene que almacenarse la misma información, y para ello, se necesita disponer de la información (tablas, relaciones, contraints, triggers y actualizaciones) involucrada en una transacción, para que puedan almacenarse de forma correcta, tal que estas transacciones se puedan sincronizar con el servidor central cuando ‘vuelva la conexión’.
Esto que estas mencionando (que pueda almacenar en estructuras paralelas) es parte de la REPLICACIÓN, y el escenario que propones (cambiar de estructuras automáticamente, al perderse la conexión) se llamaría mirroring (que además de hacer replicación, pueda cambiarse de una base a otra ‘en caliente’, sin dejar de trabajar).
Vamos a ver hombre, es muy sencillo, obviamente se necesitará tener algún sistema de replicación pero no es lo mismo, la idea a la que tú te refieres propone una copia o duplicado exacto de la base de datos de un servidor en otro, lo que yo propongo no es lo mismo y además una cosa no excluye la otra.
Aparte de aportar cuestiones técnicas que me parecen muy interesantes, la idea ¿te parece bien o no?, ¿ayudaría a la hora de dar valor a tus productos en la nube o no?, porque tu llegas con tu súper ERP instalado en la nube y le explicas al cliente:
Mira además de lo bien que funciona y lo bonito que es, podrás acceder desde cualquier parte a tu súper programa de gestión, desde la cafetería, desde el sillón de tu casa, desde la playa, y el cliente, muy bien, muy bien y si se cae la conexión a internet…
Tú que le contestas, que se espere a que vuelva, que se vaya a tomar un café o dos, que le haga más caso a la mujer que la tiene abandonada…
Él te dirá, bueno pues me quedo con mi Open Bravo, que además de hacer todo eso que tú me cuentas, trabaja offline (como todos los ERP que trabajan en la nube)
Yo particularmente sé que votaré, tú si no quieres pues no lo votes, pero te aseguro una cosa si Velneo implementa esta característica en su software, te será mucho más fácil vender el tuyo.
Bitcodesoft, la replicación no tiene porque ser total, ninguna definición dice eso.
Y no se de donde sacas que me opongo, lo que te digo es que la ‘idea’ está redundante, si se resuelve la idea de replicación existente, se resuelven muchas otras cosas, por ejemplo, esto que llamas vClient offline, o el backup en caliente.
Dividir los votos no es lo mejor cuando quieres hacer notar una idea. De hecho, en su momento, lo opuesto se hizo al crear una idea concentrada de reportes, por poner un ejemplo de algo que se hizo en Velneo.