>Seulement voilà, tout ça sont des applications dans lesquels les objets (s'il y a) sont bien compartimentés et sans relation avec ceux des autres objets.
Que ça manque de standards est une chose (mais ça change). Que les applis soit "compartimentés" je ne suis pas d'accord.
Dans un bureau Gnome, les applis partagent les mêmes librairies, la configuration est centrale. Si tu changes le proxy dans le paneau de configuration, epiphany est au courrant et utilise le nouveau proxy. Si tu changes le thème, toutes les applis en sont informées et applique le nouveau thème, si t'ajoute un codec à gstreamer tous les programmes qui utilise gstreamer peuvent utiliser ce nouveau codec, si tu étends gnome-vfs toutes les applications qui utilise gnome-vfs en profite, etc.
J'ai l'impression que tu fais une fixation sur les termes. Appèle Gconf l'"objet configuration" si "ça passe mieux" pour toi. Appèles gnome-vfs "objet stream", gstreamer "objet multi-media" qui utilise l'"object stream". L'"objet multi-media" est un membre "objet codec" qui a les méthode play(), seek(), record(), un fichier .avi est une objet video_data, un fichier .avi dans nautilus est l'objet video qui regroupe l'objet video_data et multi-media.
> Pour satisfaire la communcation inter-application
Ça ne manque pas de moyen de communication qui sont _standardisés_ (pour gnome):
- dbus (bus système, session ou application). Dédié circulation de donnée et limité à la machine (pas de réseau).
- bonobo (plus lourd que dbus, ne transporte pas que des donnés. Peux aussi transporter des "objets")
- corba/orbit. Plus bas niveau que bonobo. Permet de diffuser des "vrais" objets, de faire des requêtes sur les objets disponibles, de communiquer à distance.
> he oui, toutjours cette notion d'application
En quoi c'est un problème ?
Il y a des donnés et les applications. Il est impossible d'ignorer la notion d'application même si ça peut être vaguement caché. Notes que tu n'y arrives pas toi même. Pour des raisons "pédagogique" il est bon d'avoir la notion d'application. Si quelqu'un me demande "c'est quoi qui affiche le DVD ?", je peux lui répondre "c'est Totem". S'il n'y a pas d'application, je dis quoi ? Que la vidéo n'est pas que la video mais aussi ce qui fait l'affichage qui est un truc qu'il n'est pas connu.
Franchement aucun intérêt. Par contre l'aides à l'association de fichier (donné) à des applications (ce qui utilisent les donnés) est un plus indéniable.
> chaque desktop par exemple implémente un mécanisme
C'est un problème de standardisation. Tu peux aussi dire que Linux communique mal avec Windows. A qui la faute ?
> et si on remplaçait cette notion d'application par celle d'objets. Finalement, la seule application qui existerait serait la VM par exemple. .... .... ....
Tout ça c'est bien beau mais a 100 000 lieux des exigences _réelles_ d'un OS.
Plus tu mets de choses dans l'OS, plus tu exiges des applications et de l'OS (coût en performance).
Que doit faire tar si il tombe sur l'objet "video" ? copier tout l'objet avec le visualisateur et les préférences de l'utilisateur ? copier que les données en utilisant la méthode video::dump_stream() ? Si tar tombe sur l'objet flux_réseau, que doit faire tar ? utiliser flux_réseau::dump_stream() ?
La fonction de tar est simple. Lire des fichiers (donnés) en se balladant sur les systèmes de fichiers et les stocker. Que les donnés soit une video ou une application, il s'en fout du moment que c'est un fichier.
Certe, tar pourrait utiliser objet.is_file() . Mais tar se retrouve a tout fouiller alors qu'actuellement il ne fouille _que_ les systèmes de fichiers.
Tu ne veux pas de sur-couches mais t'arrêtes pas d'emboiter les objets. C'est la même chose.
De plus tu rends le noyau extrême fragile. Actuellement un noyau est petit. Que ce passe-il si tu mets a jours l'objet "avi" ? Tar ne pourra peut-être plus lire le fichier video (.avi) car video.dump_stream() va planter.
> pourquoi cette VM ne tournerait pas au-dessus d'un noyau ou micro-noyau.
Le problème est que cette VM "aussi sexy soit-elle" sera percée de partout.
Comment fait le compte root pour s'afficher sur cette VM si elle n'est pas du compte root ?
Avec X11, c'est simple. X11 est un serveur (l'objet :-)) d'affichage.
Lorsque je branche une clée USB, le noyau la voi, lance /sbin/hotplug, qui lance udev, puis lance hal, hal informe tout le monde via dbus, gnome-vfs récupère l'information et le dit à nautilus qui affiche une icone. Tu peux trouver ça lourd mais chaque partie fait un boulot spécifique.
- hotplug : branchement à chaud
- udev : création de fichier spéciaux pour communiquer avec le périphérique
- hal : configuration à la volé du système, base d'information du périphérique (permet de savoir si c'est un périphérique de stockage, si le périphérique de stockage est un apareil photo, etc).
- dbus : bus de communication, ici bus sur toute la machine (pour tous les programmes, toutes les sessions (ou VM, si tu préfères))
- gnome-vfs : abstraction de "fichiers" disponibles. Rassemble _tous_ les fichiers (locaux et distant).
- nautilus fait interface avec l'utilisateur.
Tu peux "bourrer" tout ça dans le noyau et mettre l'étiquette "objet", mais ça ne change rien. Il faut une "méthode" lors de l'insertion d'un périphérique (hotplug), il faut un moyen pour nommer le périphérique et y accéder (udev), un moyen pour prendre en compte les spécificités du périphérique (hal), un moyen pour communiquer à tout le monde que le périphérique est là (dbus), et un moyen pour afficher le périphirique (nautilus). Il y a gnome-vfs que tu peux virer et qui est spécifique Gnome. gnome-vfs supporte tout ce qui peut-être considéré comme fichier (ftp, nfs, samba) et ajoute un espace de nommage pour certains éléments (fonts:// preferences:// etc) pour rendre leur accès plus pratique et homogène.
Si tu réfléchis "calmement" et sans considérer que "objet" c'est forcément mieux que les "vieux conceptes" tu verras rapidement que le tout objet sucks.
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 1.
Que ça manque de standards est une chose (mais ça change). Que les applis soit "compartimentés" je ne suis pas d'accord.
Dans un bureau Gnome, les applis partagent les mêmes librairies, la configuration est centrale. Si tu changes le proxy dans le paneau de configuration, epiphany est au courrant et utilise le nouveau proxy. Si tu changes le thème, toutes les applis en sont informées et applique le nouveau thème, si t'ajoute un codec à gstreamer tous les programmes qui utilise gstreamer peuvent utiliser ce nouveau codec, si tu étends gnome-vfs toutes les applications qui utilise gnome-vfs en profite, etc.
J'ai l'impression que tu fais une fixation sur les termes. Appèle Gconf l'"objet configuration" si "ça passe mieux" pour toi. Appèles gnome-vfs "objet stream", gstreamer "objet multi-media" qui utilise l'"object stream". L'"objet multi-media" est un membre "objet codec" qui a les méthode play(), seek(), record(), un fichier .avi est une objet video_data, un fichier .avi dans nautilus est l'objet video qui regroupe l'objet video_data et multi-media.
> Pour satisfaire la communcation inter-application
Ça ne manque pas de moyen de communication qui sont _standardisés_ (pour gnome):
- dbus (bus système, session ou application). Dédié circulation de donnée et limité à la machine (pas de réseau).
- bonobo (plus lourd que dbus, ne transporte pas que des donnés. Peux aussi transporter des "objets")
- corba/orbit. Plus bas niveau que bonobo. Permet de diffuser des "vrais" objets, de faire des requêtes sur les objets disponibles, de communiquer à distance.
> he oui, toutjours cette notion d'application
En quoi c'est un problème ?
Il y a des donnés et les applications. Il est impossible d'ignorer la notion d'application même si ça peut être vaguement caché. Notes que tu n'y arrives pas toi même. Pour des raisons "pédagogique" il est bon d'avoir la notion d'application. Si quelqu'un me demande "c'est quoi qui affiche le DVD ?", je peux lui répondre "c'est Totem". S'il n'y a pas d'application, je dis quoi ? Que la vidéo n'est pas que la video mais aussi ce qui fait l'affichage qui est un truc qu'il n'est pas connu.
Franchement aucun intérêt. Par contre l'aides à l'association de fichier (donné) à des applications (ce qui utilisent les donnés) est un plus indéniable.
> chaque desktop par exemple implémente un mécanisme
C'est un problème de standardisation. Tu peux aussi dire que Linux communique mal avec Windows. A qui la faute ?
> et si on remplaçait cette notion d'application par celle d'objets. Finalement, la seule application qui existerait serait la VM par exemple. .... .... ....
Tout ça c'est bien beau mais a 100 000 lieux des exigences _réelles_ d'un OS.
Plus tu mets de choses dans l'OS, plus tu exiges des applications et de l'OS (coût en performance).
Que doit faire tar si il tombe sur l'objet "video" ? copier tout l'objet avec le visualisateur et les préférences de l'utilisateur ? copier que les données en utilisant la méthode video::dump_stream() ? Si tar tombe sur l'objet flux_réseau, que doit faire tar ? utiliser flux_réseau::dump_stream() ?
La fonction de tar est simple. Lire des fichiers (donnés) en se balladant sur les systèmes de fichiers et les stocker. Que les donnés soit une video ou une application, il s'en fout du moment que c'est un fichier.
Certe, tar pourrait utiliser objet.is_file() . Mais tar se retrouve a tout fouiller alors qu'actuellement il ne fouille _que_ les systèmes de fichiers.
Tu ne veux pas de sur-couches mais t'arrêtes pas d'emboiter les objets. C'est la même chose.
De plus tu rends le noyau extrême fragile. Actuellement un noyau est petit. Que ce passe-il si tu mets a jours l'objet "avi" ? Tar ne pourra peut-être plus lire le fichier video (.avi) car video.dump_stream() va planter.
> pourquoi cette VM ne tournerait pas au-dessus d'un noyau ou micro-noyau.
Le problème est que cette VM "aussi sexy soit-elle" sera percée de partout.
Comment fait le compte root pour s'afficher sur cette VM si elle n'est pas du compte root ?
Avec X11, c'est simple. X11 est un serveur (l'objet :-)) d'affichage.
Lorsque je branche une clée USB, le noyau la voi, lance /sbin/hotplug, qui lance udev, puis lance hal, hal informe tout le monde via dbus, gnome-vfs récupère l'information et le dit à nautilus qui affiche une icone. Tu peux trouver ça lourd mais chaque partie fait un boulot spécifique.
- hotplug : branchement à chaud
- udev : création de fichier spéciaux pour communiquer avec le périphérique
- hal : configuration à la volé du système, base d'information du périphérique (permet de savoir si c'est un périphérique de stockage, si le périphérique de stockage est un apareil photo, etc).
- dbus : bus de communication, ici bus sur toute la machine (pour tous les programmes, toutes les sessions (ou VM, si tu préfères))
- gnome-vfs : abstraction de "fichiers" disponibles. Rassemble _tous_ les fichiers (locaux et distant).
- nautilus fait interface avec l'utilisateur.
Tu peux "bourrer" tout ça dans le noyau et mettre l'étiquette "objet", mais ça ne change rien. Il faut une "méthode" lors de l'insertion d'un périphérique (hotplug), il faut un moyen pour nommer le périphérique et y accéder (udev), un moyen pour prendre en compte les spécificités du périphérique (hal), un moyen pour communiquer à tout le monde que le périphérique est là (dbus), et un moyen pour afficher le périphirique (nautilus). Il y a gnome-vfs que tu peux virer et qui est spécifique Gnome. gnome-vfs supporte tout ce qui peut-être considéré comme fichier (ftp, nfs, samba) et ajoute un espace de nommage pour certains éléments (fonts:// preferences:// etc) pour rendre leur accès plus pratique et homogène.
Si tu réfléchis "calmement" et sans considérer que "objet" c'est forcément mieux que les "vieux conceptes" tu verras rapidement que le tout objet sucks.