Recherche avancée

Sur d’autres sites (13623)

• Revision 36780 : On n’a plus besoin du pipeline body_prive puisque l’on passe par le cron ...

  31 mars 2010, par kent1@… — Log

  On n’a plus besoin du pipeline body_prive puisque l’on passe par le cron On détermine mieux le chemin des fichiers de saveauto pour le pipeline "mes_fichiers_a_sauver"

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  3 septembre 2020, par RastaPopoulos ♥

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.

  Je ne suis pas sûr de comprendre : lancer la lecture des contenus mis à jour c’est bien très exactement ce qu’on cherchait à faire avec ces attributs il me semble. Donc ça fait bien ce qu’on cherche à faire. À la louche, je pense que 99% des utilisations de rechargement ajax SPIP (avec le critère ajax + des liens ".ajax" ou des forms) concernent parfaitement des cas avec une interaction donc un rechargement qui est explicitement demandé par l’utilisateurice : clic sur un lien qui recharge un bloc ajax OU clic sur un bouton qui recharge un formulaire en ajax. Ce n’est donc pas du tout quelque chose d’imposé et de forcé : l’utilisateurice demande une ressource (lien ajax) ou poste un formulaire (ajax) qui sont alors chargés dynamiquement SANS recharger toute la page : on veut donc bien effectivement que le lecteur d’écran se mette à relire le morceau qui vient d’être chargé !

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region.

  Ces attributs sont sur des forms ajax, pas les forms non-ajax, non ? Quand on poste un formulaire ajax, alors seulement son bloc se recharge, et à l’intérieur de ce bloc, les contenus ont changé : des erreurs sont affichés, ou un message de retour final est ajouté, etc. C’est donc bien totalement voulu (l’utilisateurice a volontairement cliqué) et on veut que ça relise ce morceau puisque des contenus ont changé dedans, et souvent très important pour un formulaire (erreurs à corriger etc).

  Du coup je ne comprends pas leurs remarques : on a l’impression que tout ce qu’ils disent part du principe que ce sont des choses rechargées en arrière-plan par une volonté du dév (ce qui peut arriver dans 1% des cas, super rare), alors que non non, c’est bien à chaque fois un clic volontaire (lien ou bouton) de l’utilisateurice.

• Video editing multi customer host in server instances

  1er août 2020, par General Omosco

  I created a multi conference live stream web app using rtc and ffmpeg C api for media stream, videos/images/texts files mixed up together in realtime sending the output to rtmp multiple destinations, but unfortunately my server could not handle more than 2 conference room smoothly.

  


  The server which couldn't handle more than two conference room running ffmpeg api

  


  It is Comfort plan in OVH
Type : vps,
Processor : 4 vCore,
Ram : 8gb

  


  Usage
CPU : 100% //playing smoothly or not.
Ram : 3%

  


  My question here is that. Is it possible to be creating self isolated instance on fly and automatically deploy the app in the instance for each customer ? And the host provider that can accept that.