[AlternC-dev] Presentation ( un peu en retard)

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Remi remi+tech at b6.be
Lun 5 Mar 11:42:36 CET 2012


Salut,

Voici ma liste d'idées à moi (que d'autres ont eu avant...)

* Réunir les données propres à chaque utilisateur

L'arborescence /var/alternc/html, /var/alternc/mail/, /var/alternc/dns, 
... serait remplacée par une arborescence du type 
/var/alternc/users/0/1/2010/html, /var/alternc/users/0/1/2010/mail 
/var/alternc/users/0/1/2010/dns où 2010 est l'uid de l'utilisateur

Les données de configuration de l'utilisateur seraient synchronisées 
(dupliquées) dans le répertoire /var/alternc/users/0/1/2010/data

Cette arborescence permettrait de rendre trivial l'export/import d'un 
compte (même si cela est déjà bien avancé en non-trivial), de séparer 
totalement la notion de compte et de login, de répartir les données sur 
différents serveurs de fichiers (ou partitions pour les petits hébergeurs) 
de manière "statistiquement" équilibrée, de rendre ainsi immédiat le 
calcul du quota, de faciliter la désactivation d'un compte, la 
mutualisation des comptes de deux hébergeurs (collision de deux logins)

* Une API AlternC

Chaque utilisateur disposerait d'un clé API pour l'utilisation d'AlternC 
disponible dans le fichier
/var/alternc/users/0/1/2010/data/api_config.php

Cette clé leur permet d'accéder à toutes les fonctionnalités de 
l'interface AlternC depuis les classes AlternC mutualisées sur le serveur 
dans le répertoire /var/lib/alternc/source/

Les utilisateurs avec les droits d'administrateurs accèdent bien entendu à 
des fonctions plus avancées (gestion des utilisateurs, mais aussi 
fonctionnalités plus avancées).

* Customisation du bureau

Aujourd'hui, malheureusement, la séparation entre le coté serveur 
d'AlternC et le coté end-user n'est pas assez évidente. Le fait d'avoir 
une API permettrait de pallier cette problématique. Je ne pense pas que 
tout le monde soit fan de l'ergonomie d'AlternC (même si on lui reconnait 
nombre de qualités), ni même simplement que tout le monde ait envie 
d'avoir la même interface que l'hébergeur voisin.

Il faudrait donc, tout en continuant à proposer une interface par défaut, 
permettre facilement à chaque hébergeur d'avoir sa propre interface.

J'imagine qu'avec l'API, cela serait déjà plus évident.

Mon avis est que puisque nous aurions compartimenté les données de chaque 
utilisateur, et que nous disposerions d'une API, nous pourrions également 
compartimenter la partie serveur API distante de la partie cliente locale.

Cette partie cliente pourrait être appelée avec les droits de 
l'utilisateur final pour amener plus de sécurité et permettre à 
l'utilisateur final de la personnaliser à son tour (par surcharge de 
classe ou templates par exemple).

On pourrait très bien imaginer stocker le code appelant dans 
/var/alternc/users/0/1/2010/admin/ et enregistrer les identifiants de 
connexion dans un .htaccess/.htpasswd (cela permettrait de n'utiliser au 
sein d'AlternC que l'uid). Les logins utilisés en préfixe seraient 
remplacés par les noms de domaine (login et base SQL, login ftp).

Ainsi un compte qui change d'hébergeur peut garder ses identifiants et ne 
pas modifier le code de ses applications (login sql, ...).

* Automotisation de la prise en compte des changements

Il y a bien longtemps qu'un stagiaire avec déjà été mis sur le coup de 
faire gérer les DNS par nsupdate ce qui résoud nombre de problématiques 
comme la mise à jour "en direct" des zones, et la non nécessité d'avoir à 
parser manuellement ces fichiers. Je trouverais vraiment génial que ce 
système soit en place.

Le seul changement qui aujourd'hui n'est pas pris en compte 
automatiquement en dehors des DNS est le redémarrage du serveur Apache 
lors de l'ajout d'un sous-domaine (la faute au open_basedir sinon on 
aurait pu utiliser VirtualDocumentRoot). Il existe bien un patch 
https://bugs.php.net/bug.php?id=34663 mais les développeurs de PHP ont 
décidé que "c'est pas ma faute à moi"

Peut-être qu'avec mpm-itk, ce sera solutionné? Pas eu le temps de voir 
ça... Ou est-il sinon possible de faire un module pour PHP sans patcher 
l'original?

* Ajout d'un module de monétisation

Si AlternC pouvait gérer directement de base un module de monétisation 
(que ce soit des euros ou des grains de SEL), cela serait une grande 
avancée. Prévoir l'intégration de modules de paiement tiers comme Paypal, 
ou d'autres. Prévoir de même les mails de rappels avant l'échéance d'un 
abonnement, la désactivation automatique (avant la suppression) de la 
fonctionnalité concernée, ou encore le prépaiement pour une fonction.

Par exemple, une adresse mail coute chez l'hébergeur X "3 grains de 
sel/an", mais le pack annuel de base à 20 grains de sel comprend déjà "5 
adresses e-mail" et je peux en racheter au maximum 10. 2 moins avant la 
fin de mon abonnement pour un mail supplémentaire je suis averti qu'il 
arrive bientôt à expiration, etc.

---

Voilà, franchement, j'espère que ce ne sera pas le sujet de stage de 
Steven parce que même si ça me parait de bonnes idées, ça m'a l'air 
costaud ;)

Remi

On Mon, 5 Mar 2012, Alan Garcia wrote:

|On 02/03/2012 09:54, Jean-Philip Forest wrote:
|> Bonjour et Bienvenue à toi :)
|> 
|> Des idées de torture j'en ai plein ! Gnac-gnac-gnac ! Mais de la torture
|> pour développeur bien sûr !!
|> Il suffit de trouver des idées tordues de choses dont on peut bien se
|> passer mais qui pourrait plaire à certains.
|> 
|> Par exemple :
|> - Rendre l'interface d'admin personnalisable grâce à un fichier CSS à
|> uploader.
|J'suis sceptique sur l'interet : le mec qui connait suffisement pour
|personnaliser un CSS connait suffisement pour aller remplacer ledit css via son
|SSH/SFTP/insert_protocol_here.
|A moins que j'ai pas saisi ton objectif.
|
|> - Automatiser la sauvegarde sur des serveurs distants avec des
|> connexions ftp (par exemple). Si mon serveur pouvait se sauvegarder sur
|> ma freebox v6 en ftp ça serait le top pour la sécurité des données !!
|> (Bon j'me suis donné une idée pour me torturer tout seul...)
|Je suis assez d'accord avec azerttyu.
|
|> - Tester la compatibilité d'AlternC avec d'autres serveurs et
|> environnement de développement (Cherokee Project et Django, par exemple)
|Donc deux trucs différents :
| - pouvoir utiliser un autre truc que apache pour servir les pages. Ca veut
|dire multiplier les environnements, donc diviser les ressources pour le debug.
|C'est une bonne idée si un autre environnement que Apache apporte un vrai plus.
| - pouvoir héberger autre chose que du PHP/MySQL. Ca, c'est intégré dans
|AlternC depuis la 1.0 de manière indirecte : comme tu peux créer un template
|apache (donc propre a héberger du python ou autre) avec un fichier et un insert
|dans une table SQL, je considére que c'est OK. Maintenant, si tu peux nous
|proposer des templates apache que tu pense qu'il faudrait intégrer, je pense
|qu'on l'intégrera assez rapidement.
|
|> - Proposer l'install et la compatibilité avec PostgreSQL en permettant
|> de faire cohabiter MySQL et PostgreSQL bien sûr !
|Ya déjà un travail de séparation entre la BDD système et la/les bdd
|utilisateurs (plus le même objet).
|Comme dit Azerttyu, plus qu'a utiliser PDO en lieu et place.
|Ici, c'est pas dans les carton (if it works, don't fix it).
|
|> Je peux encore en trouver mais c'est déjà suffisant pour faire peur :p
|Hooo oui, AlternC a de quoi organiser plusieurs petit train fantome,
|mouahahaha.
|
|> Bon stage ^^
|> 
|> Djyp
|
|-- 
|Alan Garcia
|Neuronnexion, Prestataire Internet & Intranet
|21 rue Frédéric Petit - 80000 Amiens
|tel: 03 22 71 61 90 - fax: 03 22 71 61 99
|http://www.neuronnexion.coop
|_______________________________________________
|Dev mailing list
|Dev at alternc.org
|http://lists.alternc.org/listinfo/dev
|



Plus d'informations sur la liste de diffusion Dev