• # Expérience réussie

    Posté par . En réponse au journal Pourquoi on est bloqué, vers où on va peut-être pas. Évalué à 3.

    Mettez un diamant Core Object au cou d'un vieux troll tout poilu, hiérarchie vs tags, vous êtes sûr que personne ne verra la pierre précieuse.

    Trêve de plaisanterie, le dit Core Object permet d'intégrer très simplement les mécanismes d'un DVCS au sein de son application Desktop. La granularité de ce DVCS étant un objet et non pas un document, l'application gagne automatiquement un mécanisme undo/redo et un mécanisme d'édition collaborative.
    En contrepartie, il faut déléguer la partie Modèle de son MVC à une bibliothèque externe.

    C'est une réelle avancée pour le développement et la maintenance des applications. Imaginer donc, pour un traitement de texte par exemple, une fois écrit proprement l'UML de mon modèle de document et instancié ce modèle par ce mécanisme, le développement pourra se concentrer sur le contrôleur et la vue.

    Problème, Core Object s’appuie sur la gestion des objets d'un langage / d'une VM précis en l’occurrence Objective C. Afin de pouvoir généraliser ces mécanismes, il faudra penser une plate-forme de gestion des objets commune aux différents VM, langages, et frameworks.

    Il me semble inefficient (voir dangereux) que cette plate-forme commune soit uniquement disponible sous forme de SAS via Drive, iCloud, Dropbox...
    Par contre, le niveau OS ou Desktop me semble tout à fait adéquat.
    Il y a déjà des expérimentations en ce sens. Par exemple, l'interface graphique rio de Plan 9 s'appuie sur le VFS unique à chaque processus pour fournir un mécanisme équivalent. Chaque objet de l'UI d'un processus est représenté par un fichier dans son propre VFS.