SpatialBundle vs OSX Bundle

Dedicato ai miei 200 Twitter Followers

grazie di cuore ;)

La Apple promuove presso la comunita degli sviluppatori OSX un documento di 66 pagine per descrivere le varie modalita di packaging and delivering del software.
Essa considera 5 distinte aree di applicazione per tipologie di packaging:

Type Destination
Application /Applications
Framework /Library/Frameworks
Font /Library/Fonts
Documentation /Library/Documentation
Command-line tool /usr/local/bin














Un esempio pratico:

Component	Component type	Installation destination
Levon.app	Application	/Applications
Levon_User_Guide.pdf	Documentation	/Library/Documentation
SharedServices.framework	Framework	/Library/Frameworks

E' facilmente intuibile che dal punto di vista posizionale, l'applicazione Levon subisce ancora un effetto UNIX filesystem.
Lo UNIX filesystem per l'utilizzatore casalingo tipicamente monoutente è fortemente DEPRECATO per i sistemi Infodomestic Objects.

La tecnologia degli SpatialBundles di Infodomestic Objects di nuovo riducono enormemente la complessita topologica ed organizzativa anche nei confronti degli sviluppatori che devono concentrarsi sul loro prodotto piuttosto che assecondare l'architettura, la quale, dovrebbe essere sempre un servizio che faciliti il lavoro e non qualche cosa che lo rende piu complesso.

Di nuovo il processo di delivering finale di un Bundle OSX utilizza i seguenti blocchi:

Product -> Container -> Transport -> Computer

Il blocco Product è un Bundle directory quindi deve necessariamente essere inserito in un contenitore che lo riduce ad un file per poter essere agevolmente manipolato.
Il Container OSX è tipicamente un archiviatore o un file immagine (.zip || .dmg).
Nel primo caso l'utilizzatore deve attivamente estrarre il contenuto dall'archivio .zip e poi operare manipolazioni sul suo contenuto (esempio duplicarlo, attivarlo con un click, rinominarlo, etc).
Nel secondo caso (immagine DMG) il Container è un vero e proprio filesystem chiuso e rappresentato da un file.Nel momento che l'utilizzatore clicca sul file .dmg le funzioni di systema gia presenti in un computer con OSX automaticamente si preoccupano di aprire il contenitore e rendere subito disponibile alla manipolazione il contenuto.

Uno SpatialBundle Infodomestic Objects risolve drasticamente la maggior parte delle operazioni che l'utilizzatore finale deve eseguire per prendere possesso delle funzionalita del programma.
Uno SpatialBundle è Product e Container nello stesso momento quindi la complessità di retrieving e manipolazione per l'utilizzatore finale si riduce a:

SpatialBundle -> Transport -> Computer/Run

Le azioni di un utilizzatore Infodomestic Objects nel tramite di uno SpatialBundle si possono ridurre a pochi passi:

La persona trova lo SpatialBundle in internet, clicca nella pagina web, il programma automaticamente si scarica nel Desktop e si esegue.
Altro caso, la persona compra una raccolta software su supporto ottico (CDROM o DVD), trascina l'icona del programma nel desktop e poi clicca sopra ed il programma parte.

Il vantaggio principale di utilizzare un filesystem di tipo .dmg contro un .iso sta principalmente nel fatto che è possibile parcheggiare file e mantenere intatti gli attributi del file stesso con particolare riguardo all'attributo di esecuzione che in un filesystem .iso non è possibile.
Lo svantaggio è che bisogna sempre far riferimento a tecnologie di parsing OS centriche e quindi delegare alla bonta del proxy in questione l'eventualita di potersi eseguire.

Nel caso di Linux sarebbe possibile usare un semplicissimo filesystem ext2 e simulare con un proxy installato sul sistema gli stessi effetti della manipolazione di un .dmg.
In questo caso verrebbe sempre meno uno dei concetti di Infodomestic Objects ovvero decentralizzazione del potere esecutivo per passarlo in mano all'utilizzatore che usa il suo spazio protetto di memoria.
Un secondo problema che riguarda sempre la centralizzazione è relativo al comando di mount necessario per eseguire il mounting dell'immagine il quale richiede un accesso di amministratore (assolutamente DEPRECABILE).
Con una classica installazione Desktop di Ubuntu non è possibile costruire workaround efficienti per simulare l'autofissaggio (mounting) di un immagine (equivalente di DMG in OSX) cosi come avviene intimamente nel Finder di OSX.

L'unica clasuola chiesta all'utilizzatore di Infodomestic Objects è quella di abilitare la capacita di esecuzione del file, che avviene solo la prima volta per quel programma.
Questa clausola aumenta la sicurezza in quanto nel caso di malware/virus/worms allarma attivamente l'utilizzatore che sta per eseguire un programma e non, quindi, osservare un oggetto dati tipo immagine, musica, documento...

E' previsto l'inserimento di tecnologia di intelligenza artificiale per permettere un uso piu autonomo e consapevole del software permettendo che l'utilizzatore possa anche sbagliare, come sua umana natura e diritto.