[Atlankey]

Bonjour a tous, je sollicite de nouveau de votre aide, je souhaiterais faire un Serveur/Vendeur + Serveur MarketPlace, mais a ce jour avec les tous les nouveaux changements actuel, je me pose la question sur le meilleur moyen de communication entre chaques vendors.
Donc âpres avoir lu les différent post dédiée, ainsi que le guide de communications et le guide serveur j’en suis venu a la conclusion qu’aucuns moyens ne serait a 100% efficace.

En effet comme la dit Bestmomo, Elenia et Serenity, les avantages du http pose de nombreux inconvénients (comme notamment une phrase rémanente dans ma tête d’un post je crois que c’est Nibb qui la dit je c’est plus…. « le jour ou le serveur hippo plante, ce sera la hippoPanique sur SL ) lol .

Tout comme Elenia j’ai une base php/mysql, que je dois « réapprendre/réactualisé » si je code pas de php pendant un moment, et coté requêtes en revanche ( RPC…) la pour moi ces incompréhensible j’ai pas le niveau .

Bref come j’ai pas envie de me retaper les cour mysql et autres et que le codage lsl prend déjà du temps je me vois pas tripler le temps le travail pour les serveurs externe qui faut maintenir assez souvent ( sans oublier le plus important, selon les serveurs mutualisé ou dédiée, le nombre de rez sur sl va effectivement limité par la suite les requêtes sur le serveur externe. Et puis je cherche a créer des systèmes automatisé justement pour éviter tout types de maintenance et me connecter tout les jours pour cela. Je n’en ai pas le temps)

Coté requêtes Email idem, lenteurs, limites….

Quelle est le principal default de ces méthodes : par exemple sur une sim avec 20 Agents, possédant un hud avec sont script udpade, que ce soit en http ou email , lag et galeres !
--> Solution 1, un serveur /vendor sur chaques sim … impossible !
--> Solution 2-1, comme je les vu dans un autre post, un serveur web externe servant juste d’intermédiaire sur une prim serveur placé sur ma parcel, mais même la par la suite il va falloir utiliser les requête http, donc non.
--> Solution 2-2, différents serveurPrim sur plusieurs sim mettant jour leurs key , mais la aussi requête email et Timer !
--> Solution 3, Pareil que la Solution 2, combiné a un « DynDns Uuid » ( je fait référence au site Gridurl du guide ou similaire.) mais même la on en revient au problème del’hippo a savoir que ci le site ferme , eh bien on l’aura dans le baba…. !) Donc non aussi.

Pour moi la ma solution 2-2 semble être la plus approprié ce qui reviendrais par la suite a avoir des clients updater standard par requêtes email au rez ou manuel via le menu mais franchement je ne sais trop quoi en pensé donc je m’en remet vos idée et compétences.

Please

[Ahuri Serenity]

Pour de la communication inter-sims, ya pas à chercher pendant des heures, le mieux et le plus pratique c'est le HTTP.

Contrairement aux apparences, rien de bien compliqué et pas besoin d'utiliser une base MySQL à tout bout de champ. Essaies de nous préciser ton problème en donnant quelques détails et nous te mettrons sur la voie. Je vois beaucoup de gens se précipiter sur l'utilisation du MySQL comme si c'était l'unique possibilité alors qu'on peut très bien utiliser des fichiers créés ou mis à jours à la volée par exemple. S'il s'agit d'obtenir une URL permanente, acheter un nom de domaine est vraiment accessible à n'importe qui.

[Atlankey]

Eh bien je n’est pas encore commencer les scripts étant donner que justement je me demander quel moyen/support employer avant de me retaper un codage de la base du script du serveur.

Effectivement quand j’ai lu les guides j’avais opter moi aussi pour le http, d’ailleurs j’avais déjà préparer mon ftp par raaport au exemples du guide . Je possède déjà un compte orange premium pour l’hébergement donc de ce coté la pas de souci (du moin je pense ? comme je disais j’hésite par rapport au requête de rez j’ai peur que orange me bride étant donné qu’une options a 10E / mois et vu aussi que c’est orange a mon avis c’est de mutualisé de bas de gamme certes mieux que les gratuits mais moins meilleur que les ovh ou autres... mais du bas de gamme quand même !!!! lol )



Au début je ne compter pas utiliser mysql mais apparemment beaucoup se servent de la base de donné afin de pouvoir faciliter le compte rendu de leurs ventes, ainsi qu’en avoir la liste détailler et cela me permettris eventuellment de rajouter des téléporters inter-sim. Mais personnellement je trouve ca pas trop terrible ( je me base les produits de NOVATECH pour l’exemple et non pas pour la pub qui du coup donne des coordonnée fantôme si par exemple leurs téléporter et supprimer de la sim sans passé par le menu pour le désactiver, et surtout de même pour les tp stargate. Car dans mes débuts sl, je ne connaissais pas, et a mon arriver j’étais sur primabord à rezzer tout les modèles de stargate que j’avais trouvé en 0ls sans savoir que derrière il avait une extension mysql…. Pour moi c’était juste mon premier gadget que je découvrer dans le jeu… Je vous dis pas ma surprise quand au bout de 5 portes rezzer j’ai eu droit a la visite direct de leur staff me disant que je créer des entrée vide dans la base de donnée !! C’est pour cela que je voudrais éviter le plus possible le http ou du moins le mysql)
Mais la même si l’idée du htpp me tente énormément, j’ésite par rapport a ce genre de pb..



Cependant tu a tout a fais raison pour les fichiers mis à jours à la volée, qui me semble etre aussi très tentent mais je ne sais pas comment manipuler cela, et j’ai toujours cet réticence par rapport au requête externe a sl, c’est pour cela que j’avais opté pour la solution 2-2 qui permettrait au serveur de rester indépendant. Mais peut etre que jm’e trompe. ?


Je ne sais franchement pas vers ou m’orienter sauf si comme tu l’a dit on utilise juste le http (pour une communication externe/prim serveur comme dans la solution 2-1 ?)


Mon but étant de créer un serveur et vendeur network avec catégories, le plus indépendant possible sans les inconvénients que la plupart des gens rencontre avec les leurs, et que je pourrais éventuellement mettre en vente ou carrément distruber en full si on s'y met tous pour creer le vendors parfait avec également une utilisation simple et en lowlag. (oui je sais je rêve un peu trop )



Je suis dans la la plus totale! Trop d'information a la seconde, je sature


oui je sais je suis un lol. Sorry c'est aussi qu'il ya beaucoup de possibilité

[bestmomo]

Comme toujours en informatique il y a beaucoup de solutions et aucune fiable à 100% .

La question de l'utilisation d'un serveur externe à SL dépend surtout des moyens disponibles (les serveurs mutualisés ne sont pas faits pour recevoir des requêtes directes mais simplement proposer des pages http) et des compétences disponibles. Mais c'est aussi un débat de fond parfois parce que certains considèrent que tout doit être géré dans SL.

La fiabilité s'obtient par la redondance et une solution purement SL est envisageable avec plusieurs serveurs synchronisés sur des sim différents. Comme l'a précisé Ahuri la communication intersim doit s'envisager en HTTP. Évidemment tu vas buter sur les limites du LSL (surtout au niveau de la gestion mémoire) et l'absence totale de tout système de gestion de données digne de ce nom. C'est un défi .

J'avoue personnellement plutôt céder à la facilité d'un serveur externe dès que les problèmes se compliquent un peu avec une solution purement SL. Mais ça ne résout pas forcément tous les problèmes, y compris celui de la fiabilité qu'il faut de toutes façons prendre en compte, mais c'est évidemment bien plus facile dans ce cas.

[Atlankey]

yep c'est clair que que ca va être un sacré défi. mais d'un autre cote j'ai pas trop envie dy pas des jour dessus donc je vais pareil, http!

En revanche je me suis posé une question, ya une semaine on ma demander de faire un script envoyant une notecard sur un temp t a tout les membre d'un ou plusieurs groups. apparemment cela n'est pas possible de recup des keyUser ou sinon il fallait passer par un bot ( dont je ne sais absolument pas comment ca fonctionne!!!) ("mais ca c'est sujet a un autre post...")

[Ahuri Serenity]

Il y a beaucoup plus simple. Tu utilises des groupes fictifs, des listes. En programmation, on peut regrouper des informations sous forme de listes. On peut alors aisément imaginer que tes groupes seraient autant de listes consultables et éditables. L'intérêt de ces listes c'est qu'elles sont accessibles et communicable Libre à toi ensuite de conserver la liste dans le script du vendor ou sur un serveur à part qui regroupe tout. Dans mes systèmes, j'ai pour habitude de tout centraliser, c'est facile à gérer ensuite et je fais cela via un serveur web. Ca permettrait d'afficher également tes groupes sur des pages web par exemple.

[Atlankey]

Citation :

Publié par Ahuri Serenity

Dans mes systèmes, j'ai pour habitude de tout centraliser, c'est facile à gérer ensuite et je fais cela via un serveur web. Ca permettrait d'afficher également tes groupes sur des pages web par exemple.

c'est sur que ca serait le coeur si j'arrive avoir un système de ce type, mais je n'est pas assez de notions pour pouvoir le concrétisez.

j'ai également regarder sur le marketplace mais je n'est pas trouver non plus de scripts en full me permettant de le faire.

As tu mis tes scripts en vente sur le market place? ou connait tu un lien pour les acheters en full?

.

[Elenia Boucher]

Bonjour

Moi je dirais que tout dépend du confort d'administration de tes vendors. Autrement dit si tu veux une interface d'administration web, pour associer texture, items, notecard, prix ensemble, ou si on fait ça par notecard dans un serveur interne à SL (un serveur par groupe de vendors).

Par conte j'ai pas compris si tu veux faire un système rien que pour toi ou si tu compte le diffuser à des clients.

Dans le cas du confort maximal le serveur web s'impose, et il faut se cogner la partie html/css/php/mysql (c'est pas compliqué mais c'est du boulot). Dans le cas notecard une solution 100% SL est envisageable et meilleure car plus légère et plus autonome.

Dans les 2 cas la communication http s'impose, car plus souple et plus efficace. Reste à gérer les changements d'adresse. Si tu as un serveur externe pas de souci sinon il te faut un serveur interne sl rien que pour gérer ça avec une communication par mail et son uuid codé en dur dans les vendors/serveurs de vendor.

Et puis bien sur il faut sécuriser tout le système en cas de changement d'adresse du serveur externe (ou du uuid du serveur interne). Alors il faut prévoir 2 mécanismes internes à SL: un qui met à jour immédiatement de manière soft, en envoyant par http ou mail si pas de réponse la nouvelle adresse, et dans le cas ou tu as des clients un serveur d'update qui envoit une mise à jour des vendors à tes clients avec la nouvelle adresse codé en dur.
On peut rajouter les bretelles à la ceinture en mettant une mis à jour soft par serveur web sur une base de données publique mais j'ai des doutes sur la pérennité de ces systèmes.

Pour l'autre problème d'envoie des notecards dans un groupe oui il faut un bot. Soit tu en loue un, soit si tu veux tout maitriser il te faut un serveur dédié ou sous windows ou sous linux capable de faire tourner mono.

[Atlankey]

Ah super Elenia niquel chrome tu m'a exactement bien résumé la situation.

pour ceux qui est de la diffusion, si je fait un system par http je compte le garder pour moi car effectivement ya beaucoup de boulot derrière, c'est pour cela que dans ce cas je chercher éventuellement des API html/css/php/mysql tout pret.
A contrario, si j'arrive a obtenir un bon moyen de communication interne sans passer par un serveur web ( et toute la maintenance qui va avec ), je compte effectivement le diffuser car cela simplifier la vie de tous les scripteurs.

C'est pour cela que j'essai de trouver moyen alternatif interne a SL.

[Elenia Boucher]

Ton projet m'intéresse. Mais je suis surbookée et je ne pourrais pas m'en occuper avant janvier. Si tu veux que l'on constitue une équipe je serais partante sous réserve de mes disponibilités et voilà ce que je propose :

-2 type de vendor: monoprim et 9 prims, sur la base du vendor monoprim que j'ai déjà réalisé avec mon système exclusif de préchargement de texture.
-1 magic box pour déposer article, texture, notecard. Fonctionnement interne à SL si on y met une notecard adéquate ou sur serveur web autrement. On fera bien sur d'abord une version purement SL, mais en développant sans perdre de vue le web.
-Gestion des adresses par un script dans la magic box pour les vendors . Cela suffit pour la version purement SL. Et même pour une utilisation mono owner. Pour la future version 2 permettant de gérer plusieurs owners il faudra un serveur d'adresse capable d'interroger les magic box pour obtenir les adresses des vendors.
L'idée de base est que la (ou les) magic box d'un owner gére les adresses de tous les vendors du owner en question. Ainsi on a ou un système autonome, ou en cas de serveur web il suffit d'interroger la magic box pour obtenir les adresses des vendors.

-1 serveur de récupération pour nous en cas de changement d'adresse site web,

-3 Serveurs de mise à jour pour nous pour distribuer à tous les owners les nouvelles versions magic box, vendors 1 prim, vendors 9 prims.

Coté web:
Je propose d'utiliser le framework php CodeIgniter, très pratique et léger, facile à appréhender, peu contraignant, immédiatement opérationnel. Aucun souci pour s'en servir sur un hébergement mutualisé.
Développement en anglais, site multilingue fr/ang

Donc un frontal vitrine permettant aux visiteurs de visualiser les articles, avec un classement par catégorie et une recherche. Slurl sur les articles.
Et un back office avec un login permettant de gérer les inventaires des magic box et les vendors.

Version 1 mono owner. Version 2 plus tard multi owner.

Une idée sympa aussi, entre la V1 et la V2, c'est de prévoir sur le site web un accès temporaire pour configurer son vendor et qu'après le contenu de la notecard soit craché sur le chat pour fonctionner après en autonome.

Ensemble bien sur opensource sous licence GPL2

Voilà on ne sera pas trop de 2 pour développer ça. On devrait y arriver en quelques mois.

[redpurple]

Ne vous pressez pas pour le code lsl , en tout cas pour la partie transactionnelle .

Il y a une nouvelle fonction actuellement en test sur aditi ainsi qu un nouvel évènement qui pourrait faciliter la transparence des transactions
http://community.secondlife.com/t5/S...n/td-p/1239275

[Atlankey]

Super je sens qu'on va faire des miracles , je vais allez voir ton framework php pour me familiariser avec, en attentant je continue a préparer le vendor universel Mono Owner que j'ai en projet et que je pense, l'on pourra adapter très facilement, pour le moment le vendor beta fait 38 prims! mais je compte arranger facilement avec des sculpty ou des détections de face qui j'ai vérifier pour mon cahier des charges confirme bien une totalité de 5 prims a l'aise pour 12 catégories hors le socle de poses.

cela nous réduira le temps de travail vu qu'il ne resta plus qu'a gérer le cote multi Owner & communication ainsi que la sécurité.

Cela me permettra également d'ici là de finaliser mon système (exclusif aussi) d'interactivité Web 2.0 qui adaptera la shape du vendor en fonction de sa config graphique ( & d'autres surprises... )

Thanks redpurple je vais aller voir ca de-suite.

[bestmomo]

Citation :

Publié par Elenia B.

Coté web:
Je propose d'utiliser le framework php CodeIgniter, très pratique et léger, facile à appréhender, peu contraignant, immédiatement opérationnel. Aucun souci pour s'en servir sur un hébergement mutualisé.

Je ne connaissais pas ce framework, je suis allé y jeter un coup d’œil, j'aime bien l'ensemble. C'est dommage qu'il y ait une telle diversité de framework pour PHP, c'est un peu la jungle et chacun demande un investissement en temps pour une bonne prise en main. En plus certains changements de version ne préservent pas la compatibilité avec les anciennes versions, comme ça a été le cas avec synfony.

Au passage je signale l'existence d'un éditeur web simple et puissant, WeBuilder, multi-langages (http://www.blumentals.net/webuilder/) qui possède de riches bibliothèques de framework, y-compris CodeIgniter. Il est payant mais vraiment pas cher pour un usage personnel. C'est mon éditeur préféré pour tout ce qui est web développement. Je n'ai aucun pourcentage sur les ventes, je ne parle pas le letton .

[bestmomo]

En réfléchissant un peu à votre projet il me semble qu'il faut envisager avec une architecture à 3 niveaux :

1. Le premier niveau est celui du vendor dans SL avec un niveau d'autonomie suffisant pour assurer l'intendance des ventes avec ce qu'il a en mémoire. Il peut communiquer avec les serveurs de niveau 2 dans SL (communication du type 1) en HTTP. En secours il peut s'adresser au serveur de niveau 3 pour récupérer la nouvelle URL des serveurs de niveau 2 (communication du type 3).
2. Le second niveau encore interne à SL est constitué des serveurs SL. Il en faut au moins 2 pour assurer la redondance des informations. Il doit pouvoir étendre sa capacité mémoire facilement (on peut générer dynamiquement des scripts) et doit pouvoir aussi se dupliquer pour générer un autre serveur SL identique (communication du type 4). Il communique avec le serveur de niveau 3 (communication du type 2). Il offre une interface vendeur.
3. Le troisième niveau est constitué d'un serveur web avec un nom de domaine pour assurer une entrée fixe de toutes les informations. Il assure l'intendance des URL. Il gère les serveurs de niveau 2. Il offre un frontal client et une interface vendeur.
   

Bon, ce n'est qu'une ébauche rapide mais il est toujours judicieux de bien visualiser ce genre de projet. Ce qui me paraît important est la souplesse du système et son auto-reproductibilité. En particulier le serveur de niveau 2 contient toutes les informations et doit pouvoir se reproduire facilement (par exemple on pose un serveur vierge à côté et toutes les informations sont transférées par un canal du chat, on pose ensuite le nouveau serveur dans une autre sim).


Si ces quelques réflexions peuvent vous aider dans votre projet .

[Atlankey]

oui ton architecture est assez facilement réalisable, le problème qui risque alors de poser serait dans ce cas, et, au vous des récents Big-Lag des sim, la transmission des données.
(Au passage est ce que ces lag actuel sont causé par les nouveaux mode de transition http pour les textures et inventaires? possible! Mais j'ai aussi remarqué durant ma tourné sur les MM que beaucoup de NOOB offre des build, ou des hud très mal scripté avec des listens ouvert de tous les cotés... Par exemple pour un MM d'un hud de lumière ou autre, ils se réfèrent tous le wiki ou free-script.... et font générer des channel variant de "-99999 - -100" a chaques ouverture du menu et qu'ils ne referme pas! )
Serte jusque là ce n'est rien, mais en rajoutant les filtres Owner + en multipliant 20 canaux par script et encore en multipliant par le nombre de cliquers de ce même MM (en général 100 ou 150 avatar + encore une bonne 10ène de MM fait par un seul avatar dans la même journée... ca fait beaucoup le channel!!!

Or pour les serveurs et vendors utilisant une base SQL, cela nous fera perdre vite en performances. Sauf si bien sur on utilise du PL/SQL qui pourrait éventuellement nous permettre d'obtenir des gains de transmission et des gains de performances plus rapide étant donné qu'il est basé sur l'interprétation d'un "bloc" de commandes contrairement au SQL ou les ordres sont transmis et exécutés les uns à la suite des autres. Par contre je ne sais pas si ce type de langage et applicable dans les scripts LSL.

Sans oublier qu’il faut aussi gérer quelques règles de diag de base :

Le serveur (SL) a-t-il déjà fonctionnée (oui/non) ? Erreur protocole ?

Symptôme ou (Nature du défaut) constaté par le vendor :
- Pas ou plus de synchro du serveur Web.
- Pas ou plus de service du serveur Web ou Sl.

- Dilatation temporel trop longue.
- Sim de mauvaise qualité.

- Lag sur partie avatar… (Le problème se situe au niveau du router client ou du réseau IP)
> S’il existe, le problème se situe t’il au niveau des routers ou du réseau IP ( Car une personne en dégroupage total générera 3 fois plus de lag si sa tv et son Voip sont actif pendant sont jeu pour les 8-20 méga)
Le FAI de l’utilisateur n’est pas sans default contrairement a ce que l’on peut croire et, est aussi a prendre en compte lors de son utilisation du vendor et du lag générer sur les autres vendor selon le type topologie que l’ont utilisera.

[bestmomo]

On a pas attendu SL pour avoir des soucis de communication . C'est pour cette raison qu'il faut privilégier :

1. l'autonomie maximale de chaque élément
2. la redondance
3. la facilité de réplication
4. la compacité des informations transmises en les limitant au minimum
5. le contrôle inter-éléments
6. une architecture la moins hiérarchisée possible
   

Mais la partie la plus délicate n'est pas forcément au niveau des communications pour lesquelles il suffit de mettre en place des systèmes de contrôle de transmission qui alourdissent mais fiabilisent. C'est plutôt la conception du serveur SL qui demande de l'attention. Dans SL on manque cruellement de SGBD et on est toujours obligés de bricoler des systèmes forcément partiels étant donné la rusticité du langage et les limitations de la mémoire qui deviennent vite contraignantes. Passer à une gestion intégrale des données sur un serveur WEB aggrave la charge des communications.


Ça serait bien que quelqu'un nous construise un serveur de données en LSL avec des rudiments de SQL et une génération dynamique de scripts pour élargir la mémoire à la demande .

[bestmomo]

En continuant à explorer CodeIgniter j'ai constaté un bug dans leur documentation, les pages du manuel utilisateur pour les databases ne sont pas référencées. Je me suis mis à jour le fichier correspondant (bon pas repris toute la mise en page ). J'ai joint le fichier pour ceux que ça intéresse (il doit pas y en avoir tellement...). Il est ici dans la documentation :

codeigniter\user_guide\nav\nav.js

Je l'ai mis en "txt" pour que la pièce jointe soit acceptée, il suffit de remettre en "js".

[Elenia Boucher]

Citation :

Publié par bestmomo

On a pas attendu SL pour avoir des soucis de communication . C'est pour cette raison qu'il faut privilégier :

1. l'autonomie maximale de chaque élément
2. la redondance
3. la facilité de réplication
4. la compacité des informations transmises en les limitant au minimum
5. le contrôle inter-éléments
6. une architecture la moins hiérarchisée possible
   

...

Entièrement d'accord avec toi. Mais justement dans l'architecture que tu proposes le dernier point me semble poser problème: si on perd le serveur web on perd tout, en particulier les communications de niveau 2 entre serveurs SL et vendors (plus de mise à jour en cas de changement des adresses).
Aussi moi j'avais en tête un mécanisme de récupération des adresse http sur ce niveau 2 par échange de mail entre objets SL.

Citation :

Publié par bestmomo

En continuant à explorer CodeIgniter j'ai constaté un bug dans leur documentation, les pages du manuel utilisateur pour les databases ne sont pas référencées. ...

Exact. Je m'en suis pas rendue compte car j'utilise la documentation du site français http://www.codeigniter.fr/user_guide/, où il n'y a pas ce problème mais qui n'est plus tenue à jour depuis 1 an. Merci de ta contribution.

................................

[bestmomo]

Citation :

Publié par Elenia B.

Entièrement d'accord avec toi. Mais justement dans l'architecture que tu proposes le dernier point me semble poser problème: si on perd le serveur web on perd tout, en particulier les communications de niveau 2 entre serveurs SL et vendors (plus de mise à jour en cas de changement des adresses).
Aussi moi j'avais en tête un mécanisme de récupération des adresse http sur ce niveau 2 par échange de mail entre objets SL.

La référence me semble quand même être l'adresse IP fixe du serveur externe et les systèmes de sauvegarde des serveurs sont quand même efficaces (à condition bien sûr de ne pas héberger le service chez des guignols ou des mutualisés surchargés). Je n'ai jamais eu de souci de ce genre alors que les objets SL sont parfois plus fantaisistes.

Citation :

Publié par Elenia B.

Exact. Je m'en suis pas rendue compte car j'utilise la documentation du site français http://www.codeigniter.fr/user_guide/, où il n'y a pas ce problème mais qui n'est plus tenue à jour depuis 1 an. Merci de ta contribution.

Je déplore le retard de la documentation Française (la nouvelle version apporte quand même pas mal de changements), c'est pour cette raison que je n'ai utilisé que l'anglaise.

[Kaza]

Bien que la redondance est tout ça soit une bonne chose en général, il ne faut pas se surcharger ( autant en développement qu'en opérationnel ) .

Vous voyez souvent des serveurs webs plantés "tout seul" ? Des machines a trouver avec un uptime qui se compte en année ne sont pas dur à trouver . Aprés question de nez pour trouver les bons hébérgements .

La multiplication des solutions engendre tout autant la multiplication des soucis que la sécurité .

Je penche pour ma part pour du full HTTP sauf comme l'envisage momo, à la création d'une base de donnée SL "dynamique" permettant des transactions SL-SL correct .

[Elenia Boucher]

Citation :

Publié par Kaza

...
Vous voyez souvent des serveurs webs plantés "tout seul" ? Des machines a trouver avec un uptime qui se compte en année ne sont pas dur à trouver . Aprés question de nez pour trouver les bons hébérgements .
...

Un serveur web fiable est un serveur que l'on paye. Et va-t-on le payer de nombreuses années ? Là est la question. Et si la réponse est non, alors le serveur web n'est pas fiable.
Qu'est ce que l'on veut? Moi je pense un système open-source que n'importe qui pourra donc utiliser sur un serveur web gratuit. Et changer d'hébergeur de temps en temps. Donc serveur web pas fiable.

[Atlankey]

Citation :

Publié par Elenia B.

Un serveur web fiable est un serveur que l'on paye. Et va-t-on le payer de nombreuses années ? Là est la question. Et si la réponse est non, alors le serveur web n'est pas fiable.
Qu'est ce que l'on veut? Moi je pense un système open-source que n'importe qui pourra donc utiliser sur un serveur web gratuit. Et changer d'hébergeur de temps en temps. Donc serveur web pas fiable.

Je suis d'accord, mon idée de base était d'avoir un serveur web uniquement à but d'addons ( sql et php pour une interface web), ou de soutien, voir de sauvegarde... tout ayant des serveur sl indépendant, mais inter-sim pour les vendors sans passer par mail ou http. ( deja fonctionnel mais pas encore au point car manque de temp et pb personnel)

A contrario, j’envisage d’utiliser des serveur deja actif comme un service specifique a google ou bien une faille dans les appli facebook dont j’attends la reponce d'un pote qui creer des appli FaceBook justement et devrait me dire si ont peut adapter une comm entre Fb et Sl ( uniquement dans le cas pour servir de 'DynsDns" afin que l'appli fb soit vu en gros comme une @ serveur Rl pour le serveur SL dans le cas ou bien sur on sent servirais comme je disais a but d'addon pour le serveur Rl permettant des serveurs web gratuit. Et changer d'hébergeur de temps en temps )

.