🚀 go-pugleaf

Thomas Broyer <ptittom+news@free.fr> wrote in message news:<1319463.vFx2qVVIhK@ltgt.net>...

> < charge sur le r�seau snipped >
> 
> < traitement c�t� serveur snipped >

  Je suis plus ou moins de cet avis aussi. Mais il faut relativiser.
Il est clair que le fait de faire les conversions sur le serveur
all�gera dans la plupart des cas la charge du r�seau. Mais il y aura
des cas o� le fait d'effectuer ces transformations chez le client
n'induira pas une charge suppl�mentaire pour le r�seau, en permettant
par contre une �norme souplesse. Je donne ici un exemple qui me passe
par la t�te, mais il peut bien s�r y avoir d'autres applications.

  Imaginons que les furteurs, dans un avenir proche, supportent plut�t
bien la famille xsl, et qu'il fournissent un m�canisme de catalogues,
un peu comme les catalogues sgml. Ces catalogues permetteraient de
sp�cifier une feuille de style alternative pour telle url. Par
exemple, je vais sur slashdot.org, et dans mon catalogue, il y a une
entr�e du style :

    slashdot.org /home/billythekid/stylesheets/my_slashdot.org.xsl

  C'est basique bien s�r, il faut ajouter des identifiants publiques
et priv�s, et plein d'autres choses. Mais globalement, quand le
furteur va sur slashdot, il consulte le catalogue et d�couvre qu'il
doit utiliser la feuille xsl locale en lieu et place de celle
sp�cifi�e dans le document lui-m�me.

  Il n'y a donc pas de charge suppl�mentaire induite sur le r�seau. Et
plus qu'un syst�me de cache (� la "Temporary Internet Folder") ou de
gadget accessible uniquement aux programmeurs xsl, il pourrait par
exemple servir au webmaster pour proposer plusieurs feuilles de styles
*sans* l'usage de cookies.

  Ou encore, comme on peut acqu�rir maintenant des logos ou sonneries
pour t�l�phones portables, on pourrait obtenir des "skins" (xsl) pour
tel ou tel site.

  S'ensuiverait alors toute une s�rie d'outils pour permettre �
Monsieur Tout Le Monde d'afficher la page d'accueil du site de
r�sultats sportifs en rose fluo clignotant.

  Je pense aussi que dans la plupart des cas, le traitement du c�t�
serveur sera globalement le plus simple et l�ger. Mais je pense aussi
qu'il faut permettre de mani�re standard le traitement, dans certains
cas bien cibl�s, du c�t� client, sous peine de se priver d'une
souplesse �norme.
 
--drkm