Implémentation recommandée pour un client de surveillance Web de bureau? [fermé]

Question

Arrière-plan

J'ai une idée d'entreprise dont l'un des composants implique un client qui devrait être téléchargé & amp; installé par des milliers d'utilisateurs via une page Web.

Conditions d'application

Version 1:

L'application doit:

• surveillez l'utilisation d'Internet sur le bureau de l'utilisateur en surveillant les zones suivantes:

  • navigateur utilisé,
  • heures utilisées
  • sites consultés
  • prend en compte quel onglet de navigateur est "actif"

• Produire un rapport de cette utilisation (sous CSV ou dans un autre format facilement exportable)

• Il doit être facilement surveillé par l'utilisateur (par exemple, sous Windows via une icône dans la barre d'état système permettant à l'utilisateur de suspendre ou d'arrêter le programme).
• Facilement évolutif via des mises à jour automatiques.
• Doit être léger en ce qui concerne l'utilisation de la mémoire.
• doit être installé facilement et rapidement,
  • Doit pouvoir être désinstallé complètement.
• Incidence négative sur les performances du navigateur ou des utilisateurs sur le système

Pour la version 2:

• pouvoir présenter des sorties graphiques (camemberts et graphiques à barres)
• être multi-plateforme (la version 1 ne ciblera que Windows)
• Intégrer un composant en ligne

Question

Compte tenu de ces exigences, quelle implémentation technique recommanderiez-vous et quelle architecture de plate-forme / langage recommanderiez-vous? Les aspects clés sont les fonctionnalités et, au sens large, le faible impact sur les utilisateurs. ETA ou le coût sont moins critiques.

Answer 1

J'ai construit quelque chose de très similaire à celui de l'année dernière. J'ai utilisé C #. Initialement, il utilisait une partie du framework 3.5, mais je devais le redimensionner vers le framework 2.0 en raison des restrictions de taille d'installation. Il surveille actuellement environ 13 000 machines. collecte et renvoi à un serveur de rapports d'environ 3 Mo de données par minute.

Les machines clientes vont des boîtiers Pentium 4 avec 256 Mo de RAM sous XP sur des machines à deux cœurs de 2 Go.

L’application que j’ai construite ne devait pas être touchée par l’utilisateur final. Elle fonctionne donc à la fois comme un service Windows et un plug-in d’objet d’aide au navigateur pour IE. Le BHO était nécessaire pour capturer exactement ce qui se passait dans le navigateur.

Les seuls défis réels étaient de le faire fonctionner sous XP et Vista (tous les niveaux de service pack) et dans IE 6 et 7. XP et Vista ont des implications de sécurité différentes à prendre en compte; IE 6 et 7 ont également différents modèles d'accès.

Enfin, nous avons hésité à traiter avec Firefox ou d'autres navigateurs, car le client ne s'en souciait pas.

MISE À JOUR

Firefox ne prend en charge que les extensions javascript, c ++ et xul to code in; utiliser c # serait un PITA complet. J'essaierais probablement le javascript si cela suffisait parce que c'est plus facile.

En ce qui concerne Chrome, la prise en charge des extensions n’a commencé que récemment ( 19 mars 2009 ). Vous devez modifier les propriétés de démarrage du raccourci pour pouvoir les exécuter. Donc, je sauterais probablement ce navigateur jusqu'à ce qu'il arrive à maturité. J'imagine qu'il y aura beaucoup de changements dans la façon dont les plugins sont construits pour cela au cours de la prochaine année.

En ce qui concerne la quantité de données par minute, il s’agit d’une valeur globale. Chaque client individuel ne s'enregistre qu'une fois toutes les quinze minutes environ; ou lors de la reconnexion au réseau lorsque le travail est déconnecté. Le trafic individuel est donc assez faible et n’a aucun impact sur l’expérience utilisateur.

Pare-feu

La raison pour laquelle un pare-feu n'a pas d'importance pour nous est que les données sont retransmises à notre serveur de génération de rapports via le port 80 à l'aide de services Web. Si 80 est bloqué, ils ne peuvent pas naviguer de toute façon, alors il n'y a rien à collecter ... En ce qui concerne la bande passante, limitez le contenu que vous collectez et rediffusez. Les XML avec des noms d'attributs / valeurs descriptifs longs ne sont PAS votre ami.

Answer 2

On dirait que le C # conviendrait à vos besoins, à condition qu'il soit limité à un client Windows.

Answer 3

Qt et C ++ conviennent aux clients multiplates-formes - esp. s'ils ont besoin d'être "mémoire frugale" de manière à ce qu’aucune solution ne soit trouvée dans une langue usée (c’est-à-dire que tous les autres ;-) le sont généralement.

Answer 4

Nous avons besoin de plus d'informations:

Est-il temps de développer un problème? Avec C #, vous pouvez développer rapidement une telle application. mais il n’aurait pas nécessairement les mêmes performances de bas niveau que C ++. Vous pouvez développer certaines parties en C ++ (les bits gourmands en mémoire) et d'autres en C #, mais vos clients devront alors avoir le framework .NET installé; sans oublier de mentionner qu'ils pourraient assez facilement désosser les pièces C #.

Il existe un triangle de projet et nous avons besoin de savoir quels sont les deux plus importants pour vous: