Document

Title :	Xnfo Specification (french draft)
Project :	Xnfo (http://xnfo.sf.net)
Reference :	xnfo-spec-fr
Version :	0.02
Date :	18/01/2003
Author(s) :	Sanx

Changes

Date	Version	Author	Description
18/01/2003	0.02	Sanx	Addition of demo tag. Changes on category tag
09/01/2003	0.01	Sanx	Initialization of the document

Todo

Date	Author	Description
18/01/2003	Sanx	Remove os tag. Generalize the use of type attribut for code use.

Subject

This document is a working draft to follow XSD definition work.

Motivation

Il existe aujourd'hui plusieurs bases qui rassemblent les productions de la scène démo :

pouët.net : La plus récente, mais la plus importante, renseigne sur les groupes et les productions, tout est rentré à la main.
scene.org : L'hébergeur des archives de la scène.
ojuice.net : La base des démomakers et des groupes.
scenemusic.net : La base des musiques.
gfxzone.org : La base des graphismes.
D'autres nombreuses bases dédiées plus spécifiquement à des platformes ou des formats (divx, avi,...).

Il existe plusieurs sources d'informations qui permettent de nourrir ces bases :

file_id.diz : Général à tout ce qui est archive, que ce soit outil ou autre, standard à l'époque des BBS.
*.nfo : Plus particulier à la scène démo, renseigne sur la production, format non standardisé.
main : Remplir les informations à la main reste le plus courant.

Lors des démoparties, les organisateurs réalisent plusieurs choses, pour pouvoir gérer les productions :

Mise en place d'un serveur ftp, ou serveur http pour l'upload des productions. Avec réalisation de scripts de mise à jour, et pages d'enregistrement des productions.
Procédures manuelles de validation des productions, tests de l'archive, vérification de la conformité des règles de la compétition, test graphique de la production.
Des launchers : pour annoncer les productions qui passent, soit dans certains cas des bitmaps faits à la main.
Lors des démo shows, les organisateurs utilisent le meme style de lauchers.
Dès la fin de la party, les organisateurs envoient les résultats et les productions sur le serveur scene.org pour permettre à tout le monde de réccuperer les productions.

Les groupes qui réalisent les démos, ont aussi de nombreuses choses à faire :

Rédiger un .nfo comportant assez d'informations.
Standardiser les sorties d'informations.
Gérer les versions de leurs productions, gérer les mises à jour, les corrections de bugs, le déploiement sur les serveurs scene.org.
Mettre les productions sur leurs sites, rajouter les productions dans les bases de type pouet.net, avec les screenshots.
Vérifier la distribution correcte sur les ftps (archives non corrompues).

Les personnes visualisant les démos ont aussi beaucoup de travail à fournir, qui ne rend pas ca toujours facile, ni plaisant :

Recherches des productions sur scene.org, ou sur pouët.net.
Gestion de ses téléchargements (télécharger toute une party).
Téléchargement, et vérification de l'archive.
Possèder toutes les librairies necessaires, pas forcement fournies (directx, etc...).
Visualisation de la démo, et reports de bugs.
Reccupération de mises à jour des productions, des ports.
Classement des productions (et archivage).
Réalisation de shows.

Le but du projet est de réaliser un format permettant de relier tout, et de librer tout le monde des certaines tâches lourdes, et de se concentrer sur son "core buisness" : produire, gérer, et regarder des démos.

Spécifications

Définitions

production : (todo)
scener / demomaker : (todo)
demoparty : (todo)

Features

Voici la liste des informations potientiellement disponibles dans un fichier .xnfo, avec leur priorité :

Support d'une production générique de type :
- Demo
- Intro (4k, ...)
- Wild
Support de productions spécifiques :
- Music disk
- Art pack
- Diskmag
- Musique (Tracked, mp3, ...)
- Graphisme
- Invitation
- Game
- Fast
- Custom...
Party :
- Invitation (déjà dans production spécifique).
- Règles des compos.
- Productions et résultats : avec package de screenshots pour être visualisés.

Utilisateurs

La liste des utilisateurs identifiés :

user : Utilisateur normal, qui télécharge et regarde les demos.
party-orga : Organisateur de party.
scener : Scener et son groupe.
base-admin : Administrateur d'une base de type pouet, scene.org, etc...

Conception

Voici en vrac ce que pourrait contenir un fichier .xnfo :

cf. example.xnfo

Contraintes

Les informations contenues dans le fichier .xnfo se suffisent à elles-mêmes, c'est à dire que les valeurs identifiées par des codes comme les platformes et les compos devront être doublée d'une chaine de caractère afin de pouvoir en faciliter l'affichage, il est vrai que cela peut entrainer des contradictions mais ce ne sera que des contradictions visuelles car ce qui est testé est le code. exemple :

<os name="win2000sp2">PC Windows 2000 service pack 2</os>

ou encore :

<api name="directx" version="8.1">Microsoft Direct X 8.1</api>

Il n'est pas nécessaire de coupler l'information avec d'autres documents, ou une autre base. La seule "exception" serait la validation de compo, lorsqu'il y a un document qui décrit les règles. Cependant il ne sera pas necessaire de possèder le fichier de règles pour pouvoir utiliser le fichier de la production.
Les informations peuvent être reliées aux bases centrales (pouet, ojuice, etc...), mais il n'y a aucune liaison entre les différents fichiers .xnfo. Aucune information d'un .xnfo n'est redondante, la répétition entrainerait la complexité ainsi que la confusion.
Quasiment aucune information de doit être obligatoire, il ne faut pas obliger les personnes à perdre un temps fou à remplir les formulaires.

Encodage de l'information

Certaines informations seront codées afin de rendre moins vulnérable le système, par exemple pour une addresse email, il est possible d'écrire :

toto(at)trash(dot)net

au lieu de :

toto@trash.net

Explications des tags

<xnfo>

standard (float) : version du format standard xnfo.
version (uint) : version du fichier xnfo.
author (email - 0, 1) : L'adresse email de l'auteur afin de le contacter.
mode (enum : complete | partial) : quantité d'information dans le xnfo.

Souvent il y aura 2 fichiers .xnfo, le fichier partial que l'on mettra directement sur le web, et le fichier qui sera dans l'archive même. Le comportement des outils sera de reccupérer dès que possible les fichiers xnfo complets, les versions partielles étant dédiées à la distribution sommaire.

<demo>

none.

This tag permit to identify the xnfo as a "demo" xnfo (in a large meaning). It could have been a graphic tag for a graphic, a music tag for a music, or profile for a scener profile, etc.

<name>

pouetid (pouetid): identifiant pouet de la production.

CDATA uniquement pour contenir le nom de la production.

<fullname>

Le nom complet de la production.

<remix-of>

Il s'agit d'une production qui est un remix d'une autre production originale, ce tag permet d'identifier et de retrouver l'originale. Contient les tags de type : file (url, file), ou xnfo-file.

<category>

This is the category of the production, in a precise way, there is an enumeration of possible know category, but you can present custom categories, so that the text (CDATA) in this tag is the title of this custom category.

<version>

Définit la version d'une production, à travers différents sous-tags :

<major> (uint) : version majeure, la règle de changement de version est que lorsque la production change complètement, il faut incrémenter le numéro. En très grande majorité, il n'y a qu'une version majeure, la version 1.
<minor> (uint) : version mineure, lorsque la production évolue un peu.
<build> (uint) : lorsqu'il s'agit de correction de bugs plus que d'évolutions.
<preview/> (bool) : il s'agit d'une version preview, et que la production ne devrait pas être prise comme version finale. Il peut s'agir aussi d'un teaser/trailer.

<release>

Définit les informations à propos de la livraison de la production. En d'autres termes, les informations sur la sortie de la production :

<party> (string) : la party à laquelle la production est sortie.
<date> (date) : la date à laquelle elle est sortie.
<rank> (uint) : la place qu'elle a obtenu.

Il serait possible de mettre le nombre de points que la production a recu.

<authors>

Les auteurs de la production, ici les groupes ainsi que les personnes externes aux groupes.
En priorité seront mis en avant les groupes. Si la production ne possède pas de groupe, one-man prod, il sera pris le nom des personnes.
todo : completer avec person et group.

<support>

Les informations sur le support de la production, il s'agit de la configuration, des apis et des platformes supportées.
todo : completer avec configuration et api.

<credits>

Les crédits de la production, avec pour chaque personne ce qu'elle a fait.
todo : person et details.

<messages>

Les messages et les greetings, autour de la production.
todo : greetings et message.

<run>

L'execution de la production en fonction des platformes ainsi que des différentes configurations.

<autoupdate>

L'url vers le .xnfo qui est toujours à jour, et permet une mise à jour automatique.

<package>

Liste et CRC pour les fichiers de l'archive.

<archive>

Le nom et/ou l'url vers les archives.
Penser aux multidisks.

<soundtrack>

La soundtrack de la production, lorsqu'il s'agit d'une démo, une intro ou autre chose. Du même genre, on peut mettre les différentes informations spécifiques à la catégorie.

<screenshot>

Les différents screenshots de la prod.

<compo>

Les différentes informations par rapport à la compo. Destiné à la validation des règles.

Tags spécifiques

Voici quelques tags qui sont là comme spécifiques à certains types de production. Ce n'est qu'en phase d'exploration, il sera rapidement necessaire d'unifier cela, afin de rendre tout plus clair.
Un des premiers problème est d'identifier la catégorie du xnfo, il faudra donc changer le format et peut-etre rajouter une tag supplémentaire après la racine.
Graphisme :

image : nouveau type, compris dans un run ou un step.
steps, et step : Les différentes étapes du dessin.
wireframe : une version wireframe de la scène pour les gfx3d.

Video :

video : nouveau type, compris dans un run.
codec : les codecs necessaires pour faire tourner la vidéo.

Music :

format : définit le format de la musique.
num tracks : 4ch, 16ch, etc..
cover : un graphisme de couverture pour la musique.

Artpack :

Définir si l'artpack est ouvert. Si c'est le cas, il est possible d'acceder à son contenu directement à partir d'un launcher capable.
Si l'artpack est ouvert, l'information doit être redondante dans le fichier .xnfo. En fait il permet à n'importe quel artiste de diffuser son travail sans avoir a fournir un executable.

Musicdisk :

Comme pour l'artpack, le musicdisk peut être ouvert. Et comme l'artpack, il pourra être joué dans le launcher, un peu comme une playlist dans un winamp.

Party :

Invitation : Information invitant à la partie, idéalement réutilisé dans l'invit.
- information : information générale, en permettant un encodage style HTML, ou document.
- date, location, ... : les infos classiques.
- legal : toutes les informations légales.
- timetable : la timetable.
- competitions : les règles de compos.
Compo rules : Le jeu de règles pour les compos
- compo : le nom de la compo, compo classiques plus spéciales.
- description (lang="fr|en|..") : description textuelle de la compo.
- limits (size, unpackedsize) : limites de la compos.
- platforms : platformes.
- resolutions, steps : contraintes specifiques aux compos.
Party results
- compo : nom de la compo, compo classiques plus spéciales.
- jury : composition de jury.
- rank : rang de la production.
- name : nom de la production.
- credit : group ou personne qui ont participé à la compo.
- points : points en nombre de votes de la production.
- shown : la production a-t-elle montrée au public.
- disqualified : la production a e-t-elle été disqualifiée.

Outils

User

Downloader

A partir du fichier .xnfo :

le fichier archive est downloadé (en fonction de la configuration, peut être réccupéré uniquement le fichier .xnfo),
ca vérifie le CRC, et les fichiers dans le pack (attention de ne pas faire double emploi avec le format ZIP qui a pour chaque fichier de l'archive un CRC),
vérifie s'il y a une update, propose de la télécharger,
envoie la production dans le repertoire à démos sur le disque local, et classe sous la forme désirée (archive ou dépackée, nommage des dossiers, cf. organizer).

Permet de scanner un ftp et propose de télécharger les prods identifiées.

Organizer

Le but est de gérer les fichiers de démos que l'ont possède sur son disque dur. Pour organiser, il s'agit de constituer une base de fichiers .xnfo. Cette base permet potientiellement de reccuperer la production sur l'url fournie ou sur scene.org. Si ensuite on désire garder les productions sur sa machine, on peut les faire se télécharger, puis utiliser le launcher.
La façon dont les démos sont gardées sur le disque dur est paramètrée dans l'outil, on peut dire par exemple :

Mettre toutes les archives dans tel répertoire.

Mettre les archives dant un répertoire sous la forme :

/<year>/<party>/<category>/<demogroup> - <demo>

ou sous la forme :

/<year>/<demogroup>/<demogroup> - <demo>

Mettre les fichiers extraits au lieu des archives.

L'organizer contient un launcher de base qui permet d'executer la production avec le choix de configuration.

Scener

Releaser

(soit externe, soit intégré à un tool : smode, vrstudio, etc...) Un éditeur de fichier xnfo, avec un formulaire et une possibilité d'importer un fichier, avec un hint sur chaque widget pour la question à se poser afin de remplir le fichier xnfo.
Contient aussi un moteur de XSTL afin de transformer le .xnfo en fichier .nfo.
Couplé au submitter il permet de reccup les rules des compos, et de valider la production en local puis de l'uploader sur le serveur.

Party orga

Scan Ftp

Pour les orgas de parties, le programme scanne un ftp, prend les productions les valides en fonction des parametres entrés dans le système. En cas de problème, revois un message, ou éxecute une commande...

Submitter

Comme pour le scan ftp, mais direct par le réseau, et surtout possible un submit en local... Une sorte de zepo comme a l'assembly.

Validator

Le validator est un sous module des différents outils :

Scan Ftp
Submitter
Releaser

Sa fonction est de valider ou non une production à partir des règles de la party et des compos, par exemple :

Taille des fichiers.
Résolution des images.
La durée des musiques.

Il doit aussi permettre de checker les archives, ainsi que de lancer les productions afin de valider visuellement la production sur la machine de compo.

Launcher

Il permet la présentation des productions, ainsi que leur lancement.
L'outil doit être capable de charger et afficher les images, jouer les musiques et les animations. Il doit être possible de faire soit des remote launchs, soit des manual launchs sur une autre machine, avec les productions DOS. Idées :

Remplacer l'explorer de windows par le launcher / organizer pour faire une machine autonome prète à faire tourner des démos.

Organizer/Releaser (Party)

Releaser en masse les productions de la party, en rentrant les ranks. Ainsi qu'uploader le tout sur scene.org.

Marketing :)

xnfo enabled !
Une sorte de label pour les outils utilisant ou exploitant le xnfo.

Idées

Mettre au même niveau :

<file checktype="crc32" checksum="FF02FF2F">myfile.txt</file>

<url checktype="crc32" checksum="FF02FF2F">http://www.pouet.net/myfile.txt</url>

Faire un outil de démo streamé àla nectarine, bien évidement ca télécharge plutot sur scene.org, mais ca joue en direct.

Risques et problèmes

Les serveurs comme scene.org qui rajoutent un fichier scene.org dans les archives, risquent de casser le CRC. (solution : faire un injecteur de fichiers dans l'archive).
Le fichier .xnfo avec le bon CRC ne pourra être rajouté à l'archive (car le rajouter change le CRC de l'archive).
Permettre de se passer des CRC32/MD5.
Donner les règles d'incrémentations des versions des fichiers .xnfo. Par exemple ranker à la démo en tant qu'orga n'incrémente pas le numéro de version. Ou alors trouver une solution intermédiaire.
Avoir une DTD ou une XSD contenant la totalité des codes (os, api, etc...), ou fournir en ligne une liste de toutes ces codes.