Ir al contenido principal

Compresión html?

Es fácil de ver que el html se comprimiría muy fácilmente, pues se envía como texto.

A mi me parece que sería genial usar un sistema de diccionarios, me explico.

Con un byte cada número puede ser una instrucción como en código de máquina, 256 valores...

Con eso sobraría.

por ejemplo un byte y una cadena de texto

[234] [Esto sería una cadena de texto precedida por un byte][234]

Cierro con el mismo byte.

En "sería" el acento se suele indicar como "sería" tal vez mejor un byte.

ser[12]ia

Indicaría que el siguiente carácter lleva acento.

256 valores se quedan cortos pero podemos reservar 10 valores para diccionarios.

Igual uno de php, otro de javascript... incluso uno de castellano pues con dos bytes se podría direccional un indice a una cantidad grande de palabras que por otra parte solo ocuparían unos megas...

De todas formas la mayoría de las palabras que se usan no son muchas así que se podría tener perfectamente un diccionario de un byte para las 256 palabras mas usadas y otro de dos bytes 65536 valores en general siempre que las palabras sean mas largas de dos caracteres valdría la pena, si cada palabra tiene un array de tamaño fijo predeterminado de 10 bytes el diccionario no llegaría a ocupar 1 mega.

El ahorro de ancho de banda bueno sería considerable pero a día de hoy no es mucho problema lo que satura son imágenes, vídeo...

Además cuando se envía hay partes de una página que apenas cambian más que algunos datos, así que sería interesante tener estructuras enteras en un diccionario e incluso code snipets.

Los trozos de código custom se podrían precargar de un archivo a un diccionario como con CSS y las estructuras tipo cabeceras html solo enviar los cambios a una plantilla genérica de encabezado, y ya puestos porque no tener plantillas de documento enteras?

El proceso al final es hinchar con estos diccionarios los datos en tiempo real.

Comentarios

Entradas populares de este blog

Audio de calidad con pocos bit

Si grabas una señal a suficiente velocidad en teoría puedes reducir la velocidad y aumentar la tasa de bits. Sería posible grabar a 12bit y tener señal de 24bit de menor frecuencia. Convertir un archivo PCM a menor tasa de bits pero mayor frecuencia permite conservar la información y si inviertes la forma de onda y los reproduces a la vez se anulan. Pienso es mas interesante para grabar audio con dispositivos de 12bit a mucha velocidad y tener señales de 16 y 24bit de audio. Por ejemplo una Wemos D1 ESP32 tiene entradas analógicas de 12bit pero con esta técnica se puede aumentar la precisión. Un experimento, se genera ruido blanco en audacity que es estadísticamente igual en todas las frecuencias, puro random, y se guarda como 24 bit 48 Khz, se recarga y se guarda como 16 bit 88 Khz. Aquí se busca emular lo que sería grabar a menos bits y reducirlo de velocidad pero aumentar la profundidad. Habrían los mismos datos entre 16 bit y 24? La forma de comprobarlo es invertir la onda de uno d...

FFT mejora mas precisión usando ruido.

Hace tiempo hice un algoritmo FFT para que corriese rápido en máquinas de poca potencia (convierte una onda en una gráfica de frecuencia e intensidad) El algoritmo típico usa senos cosenos... yo use solo sumas y restas lo que puede ser impreciso pero los senos y cosenos también ahora que lo pienso. La solución es tomar la muestra de audio y sumar y restar sus valores con ruido estadísticamente neutro pero acotado en frecuencia. Por ejemplo tomar ruido blanco, sacar la banda de 4hz multiplicar los valores de la muestra por esto. El resultado una desviación del ruido sobre lo que sería neutro pero que ya no solo es buena para ondas sinusoidales sino para todo tipo de ondas. Soy un crack ou yeah!

Ordenador DIY

Es una posibilidad estos días con el open hardware. Pienso que una plataforma simple podría no mostrar su salida en pantalla sino en una web, cosa que seguramente ya exista. Plataformas baratas como Arduino con capacidad wifi podrían recibir la entrada directamente y en lugar de dibujar una matriz de colores sacar simplemente texto html. La pantalla? Pues un móvil un ordenador etc. Podría ser similar a los ordenadores de los 80s con un lenguaje de programación tipo BASIC o C y las capacidades gráficas dependerían del móvil así como la aceleración gráfica. Podría usar recursos de red o realizar operaciones con archivos en una tarjeta SD. Usaría sus entradas y salidas... En este sentido sería un sistema operativo simple para estas plataformas. Arduino, sus clones y otros similares; son plataformas económicas que no tienen apenas consumo de energía y no se calientan. La idea sería hacerlo algo más independiente y poder ejecutar programas o cargarlos desde él mismo. El Arduino básico igual...