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 letto una interessante recensione di questo libro relativo le influenze della proprietà intellettuale.

Che i meccanismi di gestione del copyright cortocircuitino tanto più spesso quanto più passa il tempo è questione sotto gli occhi di tutti, ciò nonostante non è semplice avere idee chiare a riguardo – per motivi a mio avviso anche legittimi.

Il libro dovrebbe focalizzarsi (non l’ho ancora comperato) sul concetto (a me caro) di innovazione e su come questo aspetto venga influenzato dalle norme che regolamentano la proprietà intellettuale.

Abolire la proprietà intellettuale
Michele Boldrin, David K. Levine
Laterza, 2012

Un link al testo in inglese: Against Intellectual Monopoly.
Link a The Magic Cauldron (html, 1999).

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

Tempo addietro ho forkato Mojolicious su github per commitare un’implementazione.
Col tempo, il mio repo forkato è rimasto indietro e volendo proporre una nuova modifica avevo necessità di allinearmi con il repository di Kraih.

Così…

Info raccolte da qua.

PS: Ma possibile che non ci sia un pulsantino comodo su github per aggiornare i fork… bah.

Alcune specifiche che vorrei tenere raccolte (pur tenendo conto che il protocollo è estensibile).

Header generici per un messaggio http.

• Cache-Control
• Connection
• Date
• Pragma
• Trailer
• Transfer-Encoding
• Upgrade
• Via
• Warning

Header specifici per request.

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• From
• Host
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Max-Forwards
• Proxy-Authorization
• Range
• Referer
• TE
• User-Agent

Header specifici per response.

• Accept-Ranges
• Age
• ETag
• Location
• Proxy-Authenticate
• Retry-After
• Server
• Vary
• WWW-Authenticate

Metodi per request.

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT

Entity header relativi l’entity body o alla risorsa richiesta. Possono essere aggiunti ai messaggi http.

• Allow
• Content-Encoding
• Content-Language
• Content-Length
• Content-Location
• Content-MD5
• Content-Range
• Content-Type
• Expires
• Last-Modified

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.