divadr escribió:Bueno, si en ese sentido si que es un poco liado.
La estructura del índice es la siguiente:
tiene 3 claves principales:
date: contiene la fecha de modificación del archivo que sea mas alta
count: el numero de archivos
list: contiene la lista de canales
dentro de list hay dos claves:
sha: contiene el sha del canal
json: contiene el fichero json del canal tal y como esta con todos su niveles... aquí es donde se podría sustituir esto y poner directamente los parámetros leídos del json sin tantos niveles, desde luego es una opción, pero como tampoco se si los json se van a quedar como están o si se van a sustituir, pues de momento lo he cargado tal cual.
En mi mensaje anterior te proponia incluir el sha y los parametros obtenidos del canal.json juntos bajo el nombre del canal y todos los canales bajo el indice list (q yo he llamado channels por concretar, pero q es igual), el indice settings del channel.json no es necesario copiarlo aqui. (es mas facil escribir el esquema q explicarlo
, de echo el codigo q puse ya deberia genera este esquema)
Yo tampoco se si los channel.json se van a quedar asi o no, pero creo q tal y como lo hemos planteado no limitamos q en un futuro se puedan añadir o modificar parametros.
divadr escribió:Bueno, a eso me refiero, que no esta la url, de todos modos la update_url, cual seria? la del json, la del .py?
Digamos q para los "oficiales" (ya se q esta definicion no gusta al jefe
) update_url = DownloadUrl (de tu updater.py)
Otro tema, creo q no hemos interpretado igual el comentario de cmos:
cmos escribió:Por cierto, creo que no se ha comentado por el hilo, pero me preguntaba si no se debería añadir algún campo en los json para que un canal se incluyera o no dentro de la actualización. Lo digo porque a veces se crea o modifica un canal o servidor que lleva consigo un cambio en una librería o la implementación de una nueva que no se añadiría hasta la siguiente versión por lo que el canal/servidor no sería funcional hasta entonces. Sé que no lo más común, pero puede darse el caso...
Yo entiendo a q se refiere a un canal subido al github q no debe ser descargado con la version actual, ya q necesita la modificacion de alguna "libreria" q no sera distribuida hasta la proxima actualizacion del plugin. En este caso coincido con @seitan y con el propio @cmos q es necesario una rama "develop" en github para estas cosas y dejar master con el codigo funcional de la version distribuida.
Por el contrario creo q tu lo has interpretado como poner un flag (o candado
) para q un canal o server modificado por mi no sea actualizable (ya q buscas el parametro "noupdate" en los archivos locales en lugar de los remotos)
PD: no me has dicho nada del nombre de mi futura empresa
): veo la estructura un poco lio, yo la simplificaria.
Pero vamos q no tiene mayor importancia.