l'intérêt d'e-venement est aussi d'être multi-sites... le serveur n'a pas toujours accès aux imprimantes locales !
L'impression peut être centralisée sur un serveur d'impression central.(CUPS permet de relayer vers des serveurs d'impression Windows). A charge pour le serveur central d'identifier les clients (IP, ou certificat par exemple), il pourra alors gérer les impressions selon le client et sa requête.
Sinon, il reste possible de mettre possible de mettre des serveurs HTTP un peu partout pour qu'ils discutent entre eux, solution beaucoup plus lourde, mais déjà utilisée par la concurrencel (pour afficher sur un second écran des panneaux « achat », « réservation » ou des annonces pour les prochaines manifestations par exemple).
L'identification par IP impose d'être sûr de son réseau. Des tunnels (sécurisés) entre les différents sites peuvent permettre d'accéder aux serveurs d'impression, à moins de vouloir les laisser avec les postes de caisse sur l'Internet.
dois-je comprendre que c'est râpé
Hmpf, oui, pour l'instant du moins. J'ai eu à utiliser d'autres solutions pour répondre à un cahier des charges musclé (expositions, musée, séances de cinéma, spectacles, évènements, abonnements, vente en ligne). La solution la plus proche de nos desiderata plantait régulièrement saturant CPU et mémoire. Une autre proposait une fonction spéciale pour rebooter le serveur depuis un poste de caisse et relancer l'ensemble du système. Celle que nous avons choisi promettait d'évoluer, mais elle était ultra-bugguée. C'est peu de le dire...
Juste un exemple, mais je me souviens m'être trouvé face à une foule de spectateurs furibards à l'encontre des pauvres caissiers, au motif que l'intégralité des postes de caisse étaient bloqués. C'était dû à des requêtes statistiques faites depuis un autre poste qui écrabouillaient les performances du serveur monstrueux hébergeant la base de données très, très mal indexée et à une connexion vers ladite base depuis un tableur où l'utilisatrice pouvait requêter librement).
Nous avons essuyé les plâtres pendant presque deux ans à coup de grosses colères et de menaces. Il a fallu plus d'une personne à plein temps pour prendre des coups et mettre de l'huile, déterminer quelles fonctionnalités étaient utilisables, comment contourner tel ou tel bug, vérifier que les résolutions des dysfonctionnement passés n'en (re)créaient pas d'autres, etc. Durant ce laps de temps, deux autres personnes furent embauchées, pour reprendre ou vérifier l'ensemble des comptes produit par le système...
Aujourd'hui le produit est stabilisé. Mais c'est vrai qu'il est scandaleux que toutes ces institutions culturelles (ou touristiques) (para)publiques qui représentent tout de même des « budgets billetteries » et une part du public non négligeables n'aient jamais songé à développer des solutions communes. L'une des rares coopération massive récente à ma connaissance a consisté à négocier des milliers de licences Microsoft pour des clopinettes (et uniquement au niveau parisien).
[^] # Re: Pas mal!
Posté par YLD . En réponse à la dépêche e-venement, la billetterie informatisée en mouvement. Évalué à 2.
L'impression peut être centralisée sur un serveur d'impression central.(CUPS permet de relayer vers des serveurs d'impression Windows). A charge pour le serveur central d'identifier les clients (IP, ou certificat par exemple), il pourra alors gérer les impressions selon le client et sa requête.
Sinon, il reste possible de mettre possible de mettre des serveurs HTTP un peu partout pour qu'ils discutent entre eux, solution beaucoup plus lourde, mais déjà utilisée par la concurrencel (pour afficher sur un second écran des panneaux « achat », « réservation » ou des annonces pour les prochaines manifestations par exemple).
L'identification par IP impose d'être sûr de son réseau. Des tunnels (sécurisés) entre les différents sites peuvent permettre d'accéder aux serveurs d'impression, à moins de vouloir les laisser avec les postes de caisse sur l'Internet.
dois-je comprendre que c'est râpé
Hmpf, oui, pour l'instant du moins. J'ai eu à utiliser d'autres solutions pour répondre à un cahier des charges musclé (expositions, musée, séances de cinéma, spectacles, évènements, abonnements, vente en ligne). La solution la plus proche de nos desiderata plantait régulièrement saturant CPU et mémoire. Une autre proposait une fonction spéciale pour rebooter le serveur depuis un poste de caisse et relancer l'ensemble du système. Celle que nous avons choisi promettait d'évoluer, mais elle était ultra-bugguée. C'est peu de le dire...
Juste un exemple, mais je me souviens m'être trouvé face à une foule de spectateurs furibards à l'encontre des pauvres caissiers, au motif que l'intégralité des postes de caisse étaient bloqués. C'était dû à des requêtes statistiques faites depuis un autre poste qui écrabouillaient les performances du serveur monstrueux hébergeant la base de données très, très mal indexée et à une connexion vers ladite base depuis un tableur où l'utilisatrice pouvait requêter librement).
Nous avons essuyé les plâtres pendant presque deux ans à coup de grosses colères et de menaces. Il a fallu plus d'une personne à plein temps pour prendre des coups et mettre de l'huile, déterminer quelles fonctionnalités étaient utilisables, comment contourner tel ou tel bug, vérifier que les résolutions des dysfonctionnement passés n'en (re)créaient pas d'autres, etc. Durant ce laps de temps, deux autres personnes furent embauchées, pour reprendre ou vérifier l'ensemble des comptes produit par le système...
Aujourd'hui le produit est stabilisé. Mais c'est vrai qu'il est scandaleux que toutes ces institutions culturelles (ou touristiques) (para)publiques qui représentent tout de même des « budgets billetteries » et une part du public non négligeables n'aient jamais songé à développer des solutions communes. L'une des rares coopération massive récente à ma connaissance a consisté à négocier des milliers de licences Microsoft pour des clopinettes (et uniquement au niveau parisien).
Comme quoi la division fait aussi le règne.