![[Logo TidBITS]](images/tblogo.gif)
Thèmes:
Copyright 1996 TidBITS Electronic Publishing. Tous droits réservés.
Plus d'informations
à la fin.
Informations:
<info@tidbits.com>.
Commentaires:
<editors@tidbits.com>.
Ce numéro de TidBITS est commandité en partie par:
Ce numéro est traduit de l'américain par:
Coordination et mise en page par :
Vous pouvez trouver ce numéro en v.o. à:
<http://www
.dartmouth.edu/pages/TidBITS/issues/TidBITS-352.html>
![[-----]](images/tbrule.gif)
Lancement de SuperCard 3.0 -- Allegiant Technologies a annoncé la version 3.0 de SuperCard qui devrait faire son apparition ce mois-ci. Cette dernière version du logiciel de développement multimédia offre de nouveaux outils d'édition et de gestion de projets, une documentation plus complète, une meilleure intégration des technologies Internet pour le développement pour le module externe pour fureteur Roadster de la même société, la reconnaissance des URL et des formats de fichiers habituellement utilisés sur l'Internet. SuperCard 3.0 devrait être commercialisé à un prix de 329 $ (US); le coût de la mise à jour devrait être de 99 $ (US). [GD]
La nature a horreur du vide; il semble que c'est aussi vrai de la presse professionnelle traditionnelle qui suit les projets de systèmes d'exploitation d'Apple (TidBITS 343). La semaine dernière, Reuters et MacWEEK ont déclenché un torrent de spéculations sur Apple, le dernier venu Be et le futur du MacOS. Tous les articles laissent entendre la parution d'un système d'exploitation Macintosh flambant neuf susceptible de tourner sur les machines à base de processeur Intel, le rachat de Be par Apple et l'arrivée d'un système hybride Copland-BeOS qui serait prêt pour la mi-1997. Ajoutez à ces articles des centaines de rumeurs toujours plus fausses ainsi que des discussions sur Internet et la barrière qui sépare la réalité de l'illusion disparait presque, du moins du point de vue de grand public.
<http://cnn.com/TECH/9610/31/apple.reut/index.html>
<http://www.macweek.com/top_stories/news_beos.html>
Apple et Be ont, tous deux, ont émis des "clarifications" pour réfuter les allégations de ces articles. Apple dément avoir adopté une nouvelle orientation en ce qui concerne sa stratégie sur le système d'exploitation; de même, pour ce qui concerne l'éventualité d'une version du MacOS complètement réécrite qui tournerait également sur les processeurs Intel. M. Marc Gonzales, directeur de Be, s'est démarqué des affirmations de Mac The Knife de MacWEEK, selon lesquelles Apple voudrait acheter une partie du BeOS pour tirer des revenus en tant que developpeur BeOS et éditeur d'autres produits BeOS. Gonzales déclare simplement que Be n'est pas intéressé par ce type d'alliance.
<http://product.info.apple.com/pr/press.releases/1997/q1/961031.pr.rel.macos.html>
<http://www.macintouch.com/beknife.html>
Toutefois, tout comme les récentes tentatives de clarification d'Apple sur ses projets quant à l'avenir du système d'exploitation, ces réponses officielles ont généré plus de questions que de réponses - ce qu'Apple déclare est occulté par ce qu'elle ne dit pas. Apple n'a pas démenti être en pourparlers avec Be pour son rachat; de même, elle n'a pas démenti étudier un système d'exploitation hybride bâti sur le micro-noyau de Copland et la couche application de Be. Ajoutez à cela un article paru aujourd'hui dans le San Francisco Chronicle qui indique qu'Apple recherche activement (pour les licencier) les employés qui sont à la source de ces rumeurs et vous avez ici ce qu'on appelle des relations publiques intenables. À ce jour, la plus officielle des déclarations d'Apple concernant ses projets de système d'exploitation est de faire une déclaration définitive "début 1997". Malheureusement, si ces rumeurs continuent, cette approche ne contribuera qu'à empirer la situation.
En ce moment, la situation est trop obscure pour qu'on puisse prévoir le dénouement de toutes ces bavardages. Cependant, Apple et Be ont bien d'autres raisons d'être en pourparlers que l'achat du système d'exploitation de Be. En effet, Be pourrait être très intéressé par les "centriciels" d'Apple (comme QuickTime et QuickDraw3D), et Apple aurait intérêt de voir le port du BeOS sur les Power Macintosh réussir, que ce soit ou non sous le logo d'Apple.
D'ici là, Be continue à travailler sur la version développeur du BeOS pour Power Macintosh (elle sera incluse gratuitement avec le numéro de janvier de la revue MacTech) et des discussions techniques apparaissent également sur les possibilités réalistes de faire tourner le BeOS sur les Macs. Nous ne pouvons qu'espérer qu'Apple et Be comprennent que le silence encourage la spéculation, et qu'ils doivent prendre les commandes de la situation, plutôt que de laisser la situation les commander.
<http://www.mactech.com/>
<http://www.macweek.com/mw_1036/news_mac_beos.html>
Cette semaine, Nisus Software devrait commencer à distribuer la version 5.0 de son traitement de texte Nisus Writer. Bien que la liste d'améliorations des fonctions et de l'interface soit longue, le principal argument de Nisus Writer pour accéder à la célébrité est que la version pour Power Mac est l'une des premières à accepter des composants OpenDoc. Cette version est également une des premières à permettre le glisser-déposer de sélections discontinues.
Cette nouvelle version est compatible avec de nombreux standards Macintosh, y compris Internet Config, Apple Guide, AppleScript (le script Do et une modeste série propre à Nisus Writer), le glisser-déposer de données entre les documents, Macintosh Easy Open, l'impression QuickDraw GX et la série de "services linguistiques" (Word Services) pour les utilitaires tiers tels que les correcteurs orthographiques et grammaticaux. J'ai particulièrement hâte d'essayer les nouvelles fonctions HTML de cette version. De plus, les utilisateurs de langues non romanes (à l'exception des utilisateurs hébreux) apprécieront la disparition de la "grenouille" ou "clé anti-piratage". Appelé "clé électronique de langue" par Nisus Writer, la "grenouille" est un dispositif spécial qui se branche sur le port ADB. Sans cette "grenouille", Nisus Writer ne fonctionne que dans un mode de démonstration limité (lire TidBITS-170).
Nisus Software conseille au moins un processeur 68020 sous Système 7.0 ou une version ultérieure, bien que certaines fonctions exigent une version plus récente du système. La version 68K requiert 4 Mo de RAM et la version Power Mac, 2 100 Ko, si la mémoire virtuelle ou RAM Doubler est utilisée) et 5 100 Ko dans le cas contraire.
Les mises à jour coûtent 89 $ (US) avec un manuel imprimé et 69 $ (US) avec la version Acrobat du manuel. Si vous demandez la mise à jour avant le 22 novembre, vous avez droit à une remise de 10%, en plus.
<http://www.nisus-soft.com/5.0_features.html>
Nisus Software -- 800/890-3030 -- 619/481-1477
619/481-6154 (fax) -- <info@nisus-soft.com>
Quand j'ai fondé Bungie Software, tout ce que je voulais faire était écrire un jeu pour ordinateur et le vendre, tout comme dans le temps où je vendais des bâtonnets glacés pendant les vacances d'été en sixième ou mes notes de cours de chimie au collège. Ma vision naïve était simple et élégante, et reflétait en quelque sorte l'innocence dans le domaine commercial.
Il n'a pas fallu longtemps pour que cette innocence soit trahie par la longue chaîne des fabricants, distributeurs, revendeurs et compagnies de vente par correspondance plus que pressés de saisir mon gâteau de leurs mains avides. Entendons nous: nous n'en serions pas au point où nous en sommes, et nous n'irions pas là où nous allons sans ces partenaires commerciaux; mais il se passe bien des choses dans les coulisses de la distribution, et les clients s'en rendent rarement compte.
Bungie a plusieurs sortes de clients. Nous vendons directement à l'utilisateur final, nous vendons aux sociétés de vente par correspondance (qui revendent à l'utilisateur final) et nous vendons aux grandes chaînes de distribution (qui revendent aux boutiques, qui revendent à l'utilisateur final). Vendre directement à l'utilisateur final est un processus simple, mais le système de distribution par détaillant est plus compliqué.
Voie 1: Vente à l'utilisateur final (facile)
A) Bungie fait paraître une pub.
B) Le client voit la pub et achète le produit.
C) Bungie expédie le produit au client.
Ici, l'étape A peut être une pub dans un magazine, un envoi direct par courrier, une lettre d'information, un site Web, une démo, etc.
Voie 2: La vente par correspondance (plus dur)
A) Bungie soumet pour évaluation un produit à la société VPC. Si celle-ci donne son agrément, Bungie n'a plus jamais à refaire ceci. (Ceci n'a plus été nécessaire pour la plupart des compagnies de vente par correspondance depuis que nous avons publié Pathways Into Darkness).
B) Bungie achète une pub. Exactement, Bungie ne vend pas un produit aux compagnie de VPC, les compagnies de VPC ont des commerciaux dont le travail consiste à vendre des pubs à Bungie (ils récupèrent des commissions au passage).
Le problème est que Bungie doit acheter la pub deux ou trois mois avant sa parution, ce qui fait que le catalogue de décembre est bouclé en octobre. Comme vous le savez, il peut être difficile de faire des prévisions pour les nouveaux produits, et la loi exige des sociétés de VPC qu'elles donnent une estimation de la date probable d'expédition, ce qui explique pourquoi elles disent fréquemment "deux semaines" alors même que Bungie dit "nous ne savons pas".
C) La société de VPC passe une commande du produit auprès de Bungie. Cette étape ne peut en aucun cas avoir lieu avant que l'étape B soit accomplie.
D) Le client voit la pub et achète le produit à la société de VPC.
E) Si la société de VPC en a trop acheté, elle renvoie le produit. Exactement, personne n'achète le produit à Bungie, ce n'est qu'un dépôt! Si la société de VPC ne le vend pas, le produit revient à Bungie. Retenez cette leçon, elle se répétera plus loin.
Remarques particulières : Pour les logiciels de divertissement, la société de VPC réalise la plus grande part de son bénéfice sur la vente d'annonces publicitaires, pas sur la vente des produits. Une publicité d'une page entière dans un catalogue d'un grand nom de la VPC spécialisé dans le Mac coûte 25.000 USD (à multiplier par 150 pages pour certains gros catalogues mensuels). Admettons que pour une annonce d'un mois, Bungie paie 9.000 USD. Si la société de VPC veut réaliser un chiffre supérieur sur la vente du produit, elle devrait en vendre 1.200 unités le mois en question, ce qui n'arrive qu'en période de fêtes de fin d'année. Considérons MicroWarehouse, une société cotée en Bourse qui réalise un chiffre d'affaires annuel de 750 millions de dollars. Elle édite quatre catalogues représentant un total de 600 pages publicitaires par mois. Ces publicités génèrent un revenu gargantuesque de 180 millions de dollars l'an. Le reste (570 millions) provient de la vente de produits, avec une marge bénéficiaire de seulement 20%. Les revenus nets sont donc de 180 millions pour les annonces publicitaires et 114 millions de dollars pour la vente de produits. Retenez cette leçon, elle se répète ailleurs.
Voie 3: La vente au détail (vraiment difficile)
A) Bungie soumet un de ses produits à un distributeur pour évaluation. Le distributeur vous répond "Bungie qui?"
B) Bungie consacre des années et beaucoup d'argent à essayer de se faire un nom afin de pouvoir tenter une deuxième approche du distributeur avec une clientèle consistante.
C) Répéter les étapes A et B aussi longtemps que nécessaire.
D) Le distributeur offre finalement à Bungie un contrat avec les options suivantes:
E) Bungie tente de négocier, mais finit par céder, comme les autres développeurs, et signe le contrat.
F) Le distributeur explique: "OK, pour placer votre produit chez le détaillant X, il faut dépenser 5 000 USD dans leur catalogue interne." Ou encore mieux, "Vous devez payer 25.000 USD pour le bout de rayon." (Le bout de rayon est le produit placé de façon ostensible à la fin d'une allée.) C'est comme ça, les gars (encore une leçon importante): quand vous rentrez dans un magasin et voyez 100 copies de Mutant Death Machine empilée au bout d'un rayon, ce n'est pas parce que le détaillant pense qu'il s'agit du jeu du siècle. C'est parce que l'éditeur a investi beaucoup d'argent pour qu'il y soit. Et cet argent sert à engraisser les revenus du détaillant.
G) Bungie vend quelques copies du logiciel au distributeur.
H) C'est alors que Bungie comprend que pour concurrencer les autres logiciels vendus par le distributeur, il doit corrompre l'équipe de vendeurs. Cela s'appelle un "spift" en américain ou une compensation. Bungie dit "OK, je te donne un dollar par unité que vous vendez à un détaillant." Une alternative est de promettre une réduction de 5% si le distributeur parvient à placer une quantité donnée.
I) OK, vient alors le pompom: le distributeur fait faillite avec une montagne de créances envers Bungie.
Maintenant, cette complainte peut s'assimiler à des pleurnicheries de la part d'une compagnie qui a gagné beaucoup de blé en vendant un jeu d'enfer, et il s'agit bien de pleurnicher. Mais, vous ne pensez pas qu'il serait bien agréable de vendre des logiciels comme l'on vend des Esquimau pendant un été torride!
[Alexander Seropian est P.D.G. et fondateur de Bungie Software et fait constamment évoluer sa fonction en engageant des collaborateurs compétents. Peut-être un jour aura-t-il suffisamment de collaborateurs compétents pour qu'il puisse passer ses journées à flâner.]
Il y a quelque temps, j'ai écrit un article pour MacWEEK à propos du manque de services d'annuaire pour le Mac, et comme c'est souvent le cas pour des publications papier, je n'ai pu inclure dans l'article toute l'information que j'avais. Voici donc une nouvelle approche du sujet avec un point de vue assez différent.
<http://www.macweek.com/mw_1035/opinion_working_net.html>
Tout a commencé lorsque j'ai demandé à mon éditeur à MacWEEK si je pouvais écrire un article sur l'utilisation de serveurs Internet de courrier électronique dans un contexte d'intranet. Je trouve les intranets très amusants puisque leur seule raison d'être est qu'ils utilisent des protocoles et logiciels Internet tout à fait standard et que, malgré cela, les publications spécialisées les considèrent comme une nouveauté. Toujours est il que le courrier électronique est un de mes sujets favoris et, du fait que nous gérons une grosse liste de diffusion avec , nous avons une connaissance approfondie des limites de la plupart des progiciels de courrier électronique pour réseaux locaux qui s'interconnectent avec l'Internet. Dans de nombreux cas, lorsqu'une entreprise a une connexion à l'Internet, il est plus simple, moins cher et plus convivial d'avoir un vrai serveur SMTP/POP que quelque chose comme QuickMail, cc:Mail ou FirstClass.
On trouve maintenant un certain nombre de serveurs SMTP/POP complets pour le Mac, de l'Apple Internet Mail Server (AIMS) - gratuit - à CommuniGate, le couteau suisse des serveurs de courrier de Stalker Software, en passant par SonicMail de Sonic System. Pour les entreprise qui ne sont pas encore connectées à l'Internet, OfficeMail de Claris utilise les protocoles SMTP et POP pour communiquer avec des clients comme Eudora et Emailer, et UUCP pour communiquer sur l'Internet (TidBITS-336.) Il y a aussi un nouveau serveur SMTP/POP de courrier pour Mac appelé RingTwice qui est actuellement en version bêta, mais lui non plus ne semble pas comporter de fonctions d'annuaire. Ajoutez tout ceci aux projets de Tenon Intersystem de créer un serveur courrier de haute capacité basé sur Post.Office et vous obtenez un vaste éventail de possibilités.
<http://www.stalker.com/>
<http://www.sonicsys.com/>
<http://grant.media-gn.nl/r2x/index.html>
<http://www.tenon.com/>
Néanmoins, parce que je ne travaille pas dans un grand organisme, il y a un problème que je n'avais pas prévu lorsque j'ai écrit cet article : les services d'annuaire. Comment pouvez-vous trouver l'adresse électronique de quelqu'un d'autre travaillant dans votre organisation? J'ai été surpris par le nombre de commentaires à ce sujet puisque j'ai toujours considéré l'Internet comme mon " grand organisme" et que, sur l'Internet, il n'y a pas de façon sûre de trouver des adresses électroniques. (Il existe des tentatives plus ou moins concluantes; les liens cités dans Finding People dans la page d'accueil de l'Internet Starter Kit for Macintosh vous amènent à la plupart d'entre elles.)
<http://www.tidbits.com/iskm/>
Partons de l'hypothèse que tous les membres d'une grosse organisation dépendent du carnet d'adresses du programme de messagerie local. Je n'ai pas utilisé QuickMail depuis 1989, et je n'ai jamais vu cc:Mail en personne, mais il me semble peu probable que tous ces carnets d'adresses contiennent autre chose que des champs pour le nom et l'adresse électronique. Que se passe-t-il si un carnet d'adresses n'a pas de champs pour un numéro de téléphone ou de télécopieur, ou pour l'adresse postale? Et à qui incombe la responsabilité d'obtenir et de saisir toutes ces données pour les membres du réseau local? Je suis sûr que toutes les organisations essayent de traiter ce problème : une personne qui a travaillé pour plusieurs publications me dit que les publications ont toujours essayé de maintenir une base de données à l'échelle de l'entreprise via Now Contact ou quelque chose de similaire, mais que ces bases de données finissaient toujours par présenter des données incorrectes et autres problèmes. Autrement dit, je soupçonne que les solutions existantes dans les progiciels de courrier électronique pour réseaux locaux ne règlent pas toujours l'ensemble du problème.
Solutions existantes -- Cela dit, comment peut-on résoudre ce problème de manque de services d'annuaire pour les serveurs de courrier Internet actuels? Il existe beaucoup de possibilités, certaines dépendant du type de serveur de courrier et de logiciel client utilisés. Le problème peut se diviser, en gros, en trois volets : la gestion de l'information au niveau du serveur, la manipulation de l'information au milieu, et la recherche au niveau du client.
De tous les serveurs de courrier Internet pour Mac, seul CommuniGate possède une fonction de carnet d'adresses (mais elle n'est disponible que via le logiciel client CommuniGator), et vous pouvez exporter les carnets d'adresses d'utilisateurs locaux dans un fichier texte tabulé. Cette fonction n'existe pas dans SonicMail ou Claris OfficeMail, et n'est disponible avec l'AIMS que via le gratuiciel MailShare Loader, disponible uniquement à l'URL ci-dessous.
<http://www.fairbanks.org/pages/fcdSite/sharedSoftware/SoftwareDirectory.html>
Si vous créez des utilisateurs dans AIMS ou CommuniGate, vous pouvez exporter une liste sous forme d'un fichier tabulé avec de multiples options. Je serais porté à importer ce fichier dans une base de données personnalisée créée avec FileMaker Pro ou dans Now Contact. Vous pourriez avoir à définir les filtres d'importation (ou même à traiter le fichier texte d'abord). Une fois vos utilisateurs inscrits dans la base de données, vous pouvez ajouter des champs non créés par le serveur de courrier électronique, trier la liste de diverses façons et, bien sûr, exporter celle-ci vers divers formats.
<http://www.nowsoft.com/products/products.html>
Une possibilité consiste à rendre simplement accessible la base de données à l'ensemble du personnel de la société. Des contraintes financières pourraient compliquer les choses, si cela implique l'achat d'une licence de site juste pour faire tourner une base de données d'identification, quoiqu'une base de données FileMaker Pro peut être convertie en un fichier exécutable (via le runtime). FileMaker Pro et Now Contact utilisent assez bien les scripts; il serait donc possible de créer un script qui permettrait d'envoyer du courrier à partir d'un client de courrier électronique acceptant les scripts, comme Eudora. Toutefois, je ne suis pas un amateur de scripts plus ou moins stables et il ne s'agirait, selon moi, que d'une solution temporaire.
Je privilégie plutot l'exportation de la liste d'utilisateurs de la base de données selon deux formats possibles. Si vous possédez une licence de site pour Eudora Pro 3.0, vous pouvez exporter la liste dans un fichier de surnoms («nicknames») Eudora, placer ce fichier sur un serveur central et copier un alias de ce fichier dans le dossier de surnoms du dossier Eudora qui se trouve sur le disque de chaque utilisateur. Eudora Pro 3.0 est parfaitement compatible avec les alias des fichiers de surnoms, mais vous pourriez verrouiller le fichier original pour prévenir les changements non autorisés. Ainsi, si vous utilisez Eudora Pro, vous pouvez utiliser le même carnet d'adresses à l'échelle de l'organisme, carnet qui comprend les numéros de téléphone et les adresses postales. Il n'est pas possible de faire la même chose avec Eudora Light puisque ce logiciel n'accepte qu'un seul fichier de surnoms.
Une autre possibilité est l'exportation vers une page Web. Le langage HTML est assez simple et il n'est pas difficile de convertir un fichier texte exporté en HTML à l'aide d'une macro de Nisus Writer, ou d'un autre outil de traitement de texte. Vous pouvez faire un pas de plus avec un CGI comme Tango, WEBFM, ROFM ou Lasso et créer un lien direct entre votre base de données et votre intranet ou le Web.
<http://www.everyware.com/Products/Tango/tango.html>
<http://www.macweb.com/webfm/>
<http://rowen.astro.washington.edu/>
<http://www.blueworld.com/lasso/>
Enfin, pour qu'on ne m'accuse pas de laisser de côté de nombreuses possibilités, il existe un certain nombre de serveurs Web construits à partir de bases de données, qui permettraient de faire cela les yeux fermés, par exemple Web Server 4D, NetWings et Webink.
<http://www.mdg.com/>
<http://www.netwings.com/>
<http://www.webink.com/>
Rendre l'information disponible sur une page Web est une chose formidable, mais elle oblige les gens à utiliser les affreux clients de courrier électronique de la plupart des fureteurs Web. Si vous aimez le client de courrier électronique de Netscape Navigator, tant mieux, mais vous pouvez configurer Navigator pour que les liens de courrier («mailto») soient envoyés à un autre programme. Copiez le court script qui suit ce paragraphe dans l'éditeur de script d'Apple, modifiez le script pour afficher le nom de votre copie de Netscape et le code de créateur de votre client de courrier électronique (l'exemple utilise celui d'Eudora) et exécutez le script. Sincèrement, je ne sais pas si les autres clients de courrier électronique peuvent fonctionner de cette façon avec Navigator, mais les versions bêtas de Eudora Light 3.0.1 semblent le faire.
tell application "Netscape Navigator 3.0"
register protocol "CSOm" for protocol "mailto:"
end tell
Sans s'attarder sur les subtilités des scripts de chaque fureteur Web, cette technique devrait fonctionner avec Microsoft Internet Explorer et Spyglass Mosaic, quoique vous pourriez avoir à exécuter le script chaque fois que vous lancez le fureteur. Pour revenir à la configuration initiale de votre fureteur, remplacez le code de créateur «CSOm» par celui de votre fureteur («MOSS», dans le cas de Navigator) et exécutez le script. Dans le cas de Eudora Light 1.5.4, vous pouvez configurer le script pour qu'il utilise l'application d'aide GURL de Eudora, qui est fournie avec Internet Config, au lieu de Eudora Light lui-même.
<http://www.share.com/peterlewis/ic/index.html>
Finalement, bien qu'il ne soit ni élégant ni intégré aux programmes de courrier autres que Eudora, le protocole Finger est toujours disponible. Celui-ci existe depuis longtemps et il peut servir à rendre disponible l'information des services d'annuaire. Il existe deux serveurs Finger (FingerToys de Acme Technologies et Daemon de Peter Lewis) ainsi que des clients Finger (y compris le Finger de Peter, une pile HyperCard Finger, sans oublier Eudora Light et Pro) mais, à ce que je sache, il n'y a pas beaucoup de gens qui se servent de Finger pour régler leurs problèmes de services d'annuaire, ce qui me porte à croire qu'il ne s'agit pas d'une solution viable.
<http://www.acmetech.com/ftoys.html>
<http://www.share.com/peterlewis/daemon/index.html>
<http://www.share.com/peterlewis/finger/index.html>
<ftp://ftp.tidbits.com/pub/tidbits/tisk/inet/finger-20-hc.hqx>
Solutions à venir -- Ces solutions de fortune sont plutôt amusantes à inventer mais elle ne sont pas le meilleur moyen de résoudre le problème de services d'annuaire. Pour cela, il semble que nous ayons besoin d'un protocole de services d'annuaire pour les serveurs de courrier électronique pour Mac ou d'un lien avec un serveur d'annuaire général.
Le protocole Ph, développé par Steve Dorner, auteur d'Eudora, pourrait être une solution. Il s'agit d'un protocole ASCII simple qui fournit une quantité suffisante d'information et qui est reconnu par Eudora et par le client Ph Mac développé par John Norstad.
<ftp://ftp.tidbits.com/pub/tidbits/tisk/inet/mac-ph-12.hqx>
Personne n'a encore développé un serveur Ph (généralement appelé serveur qi) pour Mac, ce qui représente un obstacle à la généralisation de l'emploi de ce protocole. La rumeur veut que CommuniGate et AIMS 2.0 le reconnaissent. Peut-être assisterons-nous à la renaissance de Ph?
Aussi intéressant que Ph puisse être, par sa facilité d'implémentation et son caractère textuel, un autre protocole est soutenu par la plupart des grandes sociétés. Le LDAP (LightWeight Directory Access Protocol) a vu le jour à l'Université du Michigan comme sous-ensemble du protocole d'accès aux annuaires X.500. Le LDAP a été développé par Tim Howes et deux de ses collègues de l'Université qui travaillent maintenant chez Netscape Communication. Il est donc inutile de préciser que Netscape appuie LDAP, tout comme de nombreuses autres sociétés.
Le seul client Mac qui reconnaît LDAP est le logiciel maX.500 de l'Université du Michigan, bien que Gavin Eadie travaille également sur un Live Object de fureteur LDAP pour CyberDog. Ces programmes résolvent en quelque sorte le problème des clients, mais pour qu'un protocole devienne la norme, il faut qu'il soit reconnu pas les principaux clients de courrier électronique. Le LDAP est beaucoup plus complexe qu'un protocole en format texte comme Ph, ce qui complique son intégration à un logiciel client de courrier électronique. Évidemment, Steve Dorner indique que "cette incroyable complexité est une des raisons pour laquelle X.400 et X.500 ont perdu la bataille et que l'Internet a gagné. LDAP est la revanche des grandes entreprises".
<ftp://terminator.rs.itd.umich.edu/x500/max500/max500-2.1.1.hqx>
Peut-être que le LDAP est la revanche des grandes entreprises sur les développeurs, mais sans la reconnaissance de ce protocole par les principaux clients de courrier électronique Mac et sans serveurs LDAP pour Mac (ils n'ont pas encore montré le bout du nez), il est difficile d'imaginer comment ce protocole pourrait effectuer une percée dans le monde du Mac. Avec un bon soutient, LDAP pourrait devenir la solution que tout le monde attend; d'ici là, Godot pourrait bien arriver le premier.
La solution utopique -- La solution idéale à ce problème est d'avoir un service d'annuaire intégré au MacOS. En fait, le très décrié PowerTalk offrait certaines de ses fonctions.
Quelle ironie - PowerTalk fut un bide technologique dans le traitement du courrier électronique car Apple a en partie ignoré le courrier électronique durant le développement de PowerTalk. À cela s'ajoutent des problèmes d'interface et d'architecture. Cependant, je me suis souvent entendu dire dernièrement "Bien sûr PowerTalk faisait ça". PowerTalk offrait une forme de base de données intégrée au système, il acceptait les services d'annuaire et il possédait des fonctions de "porte-clés" qui simplifiaient le traitement par les serveurs des identificateurs d'utilisateurs et des mots de passe. Ces technologies, de même que celle qui devait permettre de remplacer l'embarrassant Sélecteur, seraient les bienvenues aujourd'hui, si seulement elles n'avaient pas eu à traîner toute cette surcharge système et tout le poids d'un client de courrier électronique à peine fonctionnel.
Quand Apple a cessé le développement de PowerTalk, je me souviens de discussions au cours desquelles on affirmait que la technologie ne disparaîtrait pas complètement et qu'elle réapparaîtrait en pièces détachées dans les versions à venir du MacOS. Peut-être pouvons-nous espérer la réapparition de ces technologies, quelles qu'elles soient, dans les prochaines versions de MacOS.
Tous les numéros (en anglais) sont disponibles soit en
utilisant FTP soit sur le Web:
<ftp://ftp.tidbits.com/pub/tidbi
ts/issues/>
<http://www.dartmouth.
edu/pages/TidBITS/TidBITS.html>