Da un po’ di tempo a questa parte tutti i web framework presentano riferimenti all’architettura REST che propone di sfruttare completamente (?) le potenzialità del protocollo HTTP senza livelli aggiuntivi (ie SOAP).

• Domande e risposte su stackoverflow
• Steve Klabnik: e Haters gonna HATEOAS
• Dr. Elkstein: What is REST?
• R. T. Fielding: REST APIs must be hypertext-driven

Poi, se proprio vogliamo farci del male… Architectural Styles and the Design of Network-based Software Architectures di Roy T. Fielding.

Ho rispolverato alcuni appunti cartacei relativi i Ruoli di Perl Moose che riporto qui.

• I ruoli rappresentano comportamenti condivisi fra le classi
• La classe fa ciò che dice il ruolo.
• I ruoli non sono classi; infatti i ruoli non si ereditano e non si istanziano.
• I ruoli vengono consumati da classi o da altri ruoli.
• I ruoli sono composti in una classe con la funzione with.
• Tutti i metodi, modificatori, attributi definiti in un ruolo sono aggiunti direttamente alla classe che consuma il ruolo.
• Attributi e metodi appariranno come se fossero definiti nella classe.
• Una sottoclasse della classe consumata (cioè con il ruolo) eredita tutti questi metodi/attributi.

Riferimenti:

• Moose::Role
• Moose::Manual::Roles

LaTeX è un linguaggio di markup basato sul TeX – un programma di tipografia digitale progettato da Donald Knuth.

I pacchetti relativi tex minimi su Debian sono i seguenti (discendono dall’installazione di texlive-base, e dipendono dalla distribuzione textlive):

libkpathsea5

luatex

tex-common

Pacchetto con file in comune e documentazione generica su TeX e Debian

texlive-common

texlive-doc-base

Documentazione TeX Live

texlive-binaries

texlive-base

Pacchetti necessari per usare LaTeX.

texlive-latex-base

texlive-latex-recommended

Pacchetti aggiuntivi.

preview-latex-style

texlive-pictures

texlive-latex-extra

Ho trovato interessante il tabellone linkato perchè almeno può dare una direzione da seguire per colmare quel che manca.

Smanettando con Mojolicious, mi sono ritrovato a guardare meglio il protocollo http (rfc 2616), che in effetti ho sempre usato ma approfondito poco.
Un po’ di info estese si possono trovare su wikipedia, ma in sostanza HTTP è un protocollo che si basa su richieste di uno user agent (client) e risposte di un web server (server).

Generalmente ad una richiesta del client segue una risposta del server che può fornire risorse di qualunque genere, anche se generalmente server file HTML – interpretati poi dal client; un messaggio di risposta contiene informazioni sullo stato (attraverso un codice numerico), vari header, e eventualmente un contenuto.

Le risorse HTTP sono identificate da URI (Uniform Resource Identifiers) o, più precisamente, URL (Uniform Resource Locators) che ne permettono la chiamata.

La principale differenza fra la versione del protocollo 1.0 e la 1.1 è che la specifica più recente permette di riutilizzare la medesima connessione più volte – mentre la versione più antica richiedeva una connessione separata per ogni transazione richiesta-risposta.

Richiesta

Un messaggio di richiesta può presentarsi come segue:

La richiesta presenta un metodo, un URI e un protocollo, alcuni header aggiuntivi, e la linea “Host:” che determina a chi stiamo chiedendo la risorsa (obbligatorio nella v. 1.1).

Risposta

La risposta del server alla nostra richiesta è la parte interessante. In cima c’è lo status della risposta, seguito da una serie di header che possono fornire informazioni aggiuntive di vario genere; infine, dopo una riga vuota, segue il corpo.

Un body se presente mandato via HTTP request o response è in un formato codificato definito dagli header.
Quando un corpo (entity-body indica l’insieme di oggetti serviti come corpo – compresa ad esempio una codifica di sicurezza) è incluso in un messaggio, il tipo del body è determinato via Content-Type e Content-Encoding.
Il Content-Type specifica il tipo di media e l’Encoding può essere usato per, ad esempio, compressioni applicate ai dati; non vi è alcun Content-Encoding di default.

Qualunque messaggio HTTP/1.1 contenga un body dovrebbe includere un Content-Type: in caso di mancanza, il client può provare a capire cosa gli viene mandato; se l’ispezione non ha successo, il ricevente dovrebbe trattare il file come “application/octet-stream”.
Anche il Content-Length è molto importante perchè fornisce informazioni sul numero di byte passati.

Volevo vedere questa gamma di caratteri nei browser su titanio, e ho dunque installato i pacchetti debian

• ttf-wqy-microhei
• ttf-wqy-zenhei
• xfonts-wqy

It works!

The purpose of this package is for applications that only support OSS to depend on it, hence preventing common “/dev/dsp not found” errors that would confuse unexperienced users.

sim@titanio:~$ apt-cache show oss-compat
Package: oss-compat
Version: 0.0.6
Installed-Size: 72
Maintainer: Debian Games Team

Architecture: all
Depends: module-init-tools | hurd
Description: Open Sound System (OSS) compatibility package
 This package ensures that Open Sound System support is provided in
 some way. On Linux, it enables the ALSA compatibility modules. On
 other kernels where OSS is the default interface, no action is
 taken.
 .
 The purpose of this package is for applications that only support OSS
 to depend on it, hence preventing common "/dev/dsp not found" errors
 that would confuse unexperienced users.
Tag: admin::configuring, role::app-data, special::auto-inst-parts,
works-with::audio
Section: sound
Priority: extra
Filename: pool/main/o/oss-compat/oss-compat_0.0.6_all.deb
Size: 3962
MD5sum: 888fa2d88f12049faecaf61792281f0b
SHA1: 4aad2073ba67303f9fd22fcad502cf6d72b9a757
SHA256: 171cb887c9e9152f5974cecb94f53ee181ca542a8814cdd9f00d2f40ab0b9bfe