TImaniac a écrit 6420 commentaires

Ben y'a pleins de composants IMAP pour .NET, mais la plupart payant :-/ j'ai trouvé ca par contre :
www.codeproject.com/csharp/IMAPLibrary.asp
pas essayé par contre.

Franchement le format MSI existe depuis déjà un moment et permettrait théoriquement de faire pleins de choses, de l'installation à la désinstallation en passant par les mises à jour (j'ai même envie de dire mieux géré que sous nux, ou la mise à jour consiste souvent au téléchargement complet de la dernière version du paquet). Il est même de plus en plus répendu et beaucoup d'installeur setup.exe ne sont que des bootstraps sur un installeur msi.
Le vrai problème c'est d'unifier et de rassembler tout les softs sur un même serveur. Mais la plupart des softs sont proprios et veulent avoir leur propre vecteur de diffusion. Pour preuve les softs proprio sous nux qui ne profitent que très (trop) rarement des possibilités des gestionnaires de packages des distributions.

Ben avec le docbook comme ca je sais pas, une méthode de porc consisterait à copier coller du code html colorisé dans OOWriter puis d'exporter en PDF, mais j'avoue que c'est pas terrible quand même.

En fait l'objectif initial n'était pas de faire un cours sur le langage C#, mais plutôt de présenter les spécificités de la plateforme, notamment à travers ses bibliothèques et ses outils.
J'ai voulu rappeler le mode de compilation "à la C" avec différenciation entre executable et bibliothèque, et la manière de les compiler avec Mono.
Je penses qu'il y a suffisament de cours sur le langage C# sur le net, notamment en français. Mais il est vrai que j'aurai pu donner justement quelques liens et signaler quelques pré-requis. D'ailleur je ne suis pas tellement cohérent avec moi même puisque je présente par exemple la notion d'événement ou les génériques :)

Enfin promis si j'ai le temps je ferais un tutorial sur les principaux aspects de C#, mais ce n'est pas ma priorité puisqu'il y a déjà de nombreuses ressources en français dessus.

Voila ce que ca donne chez moi :
http://pascalfresnay.free.fr/divers/bug.png(...)
y'a des retours à la ligne non prévus. A noter que j'utilise un script côté client pour la coloration.

merci c'est corrigé

Pour te faire encore plus plaisir je t'ai mis une première version PDF (si jamais tu ne peux pas lire le sxw) :
http://pascalfresnay.free.fr/monoweb/mono_ooo.pdf(...)
(jai pas mis le lien vers le site parcque je n'ai pas la mise en forme actuelle)

Je me permet au passage de me prononcer sur mon rejet profond et sincère de docbook et des documents html générés avec.
Franchement j'ai du mal à comprendre. Ce n'est pas parcque je n'ai pas mis les sources qu'il faut rejeter la cause sur le format docbook !

Pour ton problème de lecture offline je ne vois au contraire que des avantages dans le format DocBook : génération de site web statique (donc facile à pomper, pas comme un site dynamiquement en PHP qui attaque une BDD par exemple), possibilité de générer le site sur une seule page web, possibilité de générer le site en PDF, bref c'est que du bonheur pour le offline.

C'est juste que j'ai uploadé le site y'a 2h et que je n'ai pas encore eu le temps (franchement désolé) de mettre en ligne de version PDF ou les sources.
Pour la version PDF j'ai envi d'avoir un rendu propre avec colloration syntaxique par exemple, donc j'attend un peu. En attendant tu peux toujours récupérer les sources ici :
http://pascalfresnay.free.fr/monoweb/src/mono.sxw(...)
(vi j'ai utilisé ooo2dbk)

J'en profite moi même pour poser une question :
Si vous allez à cette page :
http://pascalfresnay.free.fr/monoweb/ar01s04s06.html(...)
il y a un morceau de code sous la ligne
"Voici le listing du programme principal implémentant cet algorithme à l'aide de l'introspection :"
Et là j'ai des retours à la ligne intempestifs en pleins milieux, et seulement avec le moteur Gecko (firefox, mozilla & co)... Sous IE c'est nickel, et dans les autres morceaux de code je n'ai pas le même problème !
Si quelqu'un a une explication :-/

Le chapitre un en même que l'index c'est obligatoire?
Non ce n'est pas obligatoire mais faut que j'aille modifier plus en prodondeur la feuille XSL, parcque par défaut le lien vers l'index est foireux si je lui dis de le générer à part :-/
Qu'est ce que tu appelles des touches d'accès rapide ?

Disons que tu peux considérer que tout est objet, bien que techniquement ce n'est pas le cas. Les types primitifs sont automatiquement convertis dans leurs équivalent objet (autoboxing) et inversement, évitant ainsi au programmeur de faire la différence.
Par exemple :
ArrayList list = new ArrayList();
for(int i = 0; i < 10; i++) list.Add(i); //pas besoin de faire new Int32(i)
int total = 0;
foreach(int i in list) total += i;
Console.WriteLine(i);

A noter que ce comportement est désormais présent dans Java 1.5

Dans la pratique C# distingue également les structures qui ne peuvent pas posséder de méthodes virtuelles (donc pas vraiment objet) mais peut implémenter des interfaces par exemple. La principale différence vient du fait que les structures sont allouées sur la pile et non sur le tas, et sont passées par valeur et non par référence.

Bah oué c'est 100% docbook, avec la feuille de style officielle quasiment pas modifiée :)

Pour le lien concernant les avis respectifs des 2 éditeurs logiciels :
http://rss.zdnet.fr/actualites/informatique/0,39040745,39223370,00.(...)
(bon la source n'est pas une référence, mais quand il s'agit de rapporter des paroles ils s'en sortent à peu prêt :) )

Pour ce qui est du respect par MS de son propre futur standard Metro, je croit pouvoir dire sans me tromper qu'il n'y aura pas de problème : ce standard servira de support aux nouveaux pilotes d'imprimantes du prochain OS de LongHorn, une fois les spécifs figgées et implémentées par les constrcuteurs d'imprimantes, je vois mal comment sortir du sentier battu... ce serait suicidaire de la part de Microsoft alors que son objectif avec Metro est justement l'interopérabilité et l'unicité des pilotes d'impression.

Je vois un autre atout majeur à une implémentation libre de ce format : l'utilisation des imprimantes développées pour Windows.

Le rendu de référence sera, ipso facto, celui du lecteur de Microsoft.
Il y a de fortes chances. D'où le fait que j'aurais préféré qu'il y ai un autre format, indépendant de tout éditeur :)
Enfin les imprimantes seront autant de "lecteur" figés.
MS proposera sans doute un API de rendu et ce sera sans doute le même utilisé par toutes les appli sous Windows.

Je ne vois pas comment standardiser quelque chose de fermé.
Houlà tu sais avec les brevets logiciels... Tiens prends le standard MPEG2 par exemple...

Un format est ouvert ou il ne l'est pas.
On est complètement d'accord, c'est pour ca que je voyais pas l'intérêt de chercher à départager le PDF et Metro de ce point de vue. Pour moi y'en a pas un qui est plus ouvert que l'autre. Ce que j'ai voulu dire c'est qu'il y en a aucun qui soit un standard indépendant. Effectivement il y en a un qui l'est de facto, mais gageons que celui de Microsoft va vite devenir un format standard également de facto (enfin visiblement MS et ADobe semble d'accord pour dire que les objectifs et donc les intérêts, sont différents). Mais quand je vois qu'il n'y a aucun autre lecteur que celui de Adobe capable d'afficher correctement tous les fichiers PDF je me dis qu'il y a encore du gros boulot à faire.

Pour moi un vrai standard est un standard où les principaux acteurs participent conjointement à l'évolution du format, assurant ainsi une vraie interopérabilité.

Oui, mais au moins Adobe met à disposition un lecteur pour ta plate-forme et ça, c'est un vrai plus en faveur de l'interopérabilité.
Si Adobe publiait et développait son standard avec les autres acteurs du marché (et donc les autres développeurs d'outils autour du PDF), il n'y aurait jamais besoin de ce lecteur d'Adobe. Le fait d'être content d'avoir un lecteur Adobe sur son OS favori montre bien les limites de ce standard defacto : il faut l'implémentation officielle d'Adobe, et c'est bien ce qu'ils recherchent, tout le reste n'est que tentative de support toujours à la rue.

Là effectivement c'est une autre histoire de savoir quel est l'intérêt de la FSF de changer de licence. Ils peuvent par exemple passer le GPL à LGPL, ou bien l'inverse, ou comme pour Classpath rajouter des clauses supplémentaires. On peut aussi imaginer une GPL3, avec des clauses encore différentes adaptées pour ClassPath, etc. Un autre but est d'assurer que justement tout le code est sous la même licence à tout moment.
Pour ce qui est des droits, evidemment cela ne s'applique qu'aux portions de code dont ils détiennent le copyright, mais à priori ils n'ont pas besoin de défendre les droits du code de quelqu'un d'autre, le détendeur du copyright a peut être d'autres idées, une autre éthique, etc.
Bref, s'ils demandent le copyright c'est pour avoir du code sous une licence "unifiée" et ainsi pouvoir maîtriser les éventuelle évolutions : c'est d'ailleur le cas actuellement, la FSF peut se prononcer sur la compatibilité avec la licence Apache, et peuvent si besoin est ajouter ou enlever une clause s'ils trouvent cela utile et pertinent. Avoir 15000 détendeurs du copyright rend très difficile ce genre de négociation.

Le truc c'est que le format est pas encore figé définitivement d'où leur mise en garde, mais MS a été clair quand à l'utilité et à liberté d'utilisation des spécifs : leur but est de proposer un format facilitant les échanges entre les applications.

Mais bon visiblement vous préférez discuter sur des détails entre PDF/Metro, moi je vous dis juste que je ne considère aucun des 2 comme un standard, ce sont 2 produits commerciaux, aux spécifs ouvertes certes, mais il manque un vrai standard ouvert et indépendant.

Donc si on veut se faire plusser il suffit de faire pleins de copier/coller alors que pourtant tu démontres avec force ce que j'ai dis.
Même si les spécif de Metro ne sont pas facile d'accès pour un linuxien (un .exe), les spécif sont tout de même disponibles et librement implémentable (lis la licence en question justement) : donc c'est parfaitement compatible avec l'article 4.

Enfin je trouve ton raisonnement vraiment biaisé, et de la part d'un partisan du libre je trouve que limiter la définition d'un standard ouvert à la définition de l'article 4 vraiment limitée.

Moi j'entend par standard ouvert un format défini par un consortium indépendant et reconnu (type W3C ou autre OASIS) : c'ests pour moi un vrai gage de "standardisation", et l'évolution du format en question n'est alors pas soumis aux seuls choix stratégique d'une entreprise. C'est en ce sens que pour le format PDF n'est pas plus ouvert que ne le sera Metro (j'emploi le future parcqu'il n'y a pas encore d'implémentation).

Le but était de rappeler avant tout qu'il manque un véritable format standardisé dans ce domaine, et que bien que parfaitement compatible avec l'article 4 ces formats sont développés par une seule société commerciale.

PS : au moins MS publie les spécifs avant de les implémenter, parcque Adobe sort toujours les spécifs en même temps que son nouveau lecteur, assurant ainsi que son lecteur serait toujours le seul vrai et unique lecteur toujours à jour à temps.

Je crois que tu as oublié the killer-feature (vis à vis de CVS) : on peut déplacer un dossier ou renommer un fichier.

Comme je l'ai dis la FSF n'a pas besoin de tout le copyright pour défendre ses droits dessus, alors que pour changer de licence il faut l'accord de tous les détendeurs de copyright. Donc c'est bien avant tout ce 2ème cas qui rend la cession de copyright utile.
Au moins y'en a qui le demande et qui disent vraiment pourquoi ils le font :
http://www.mono-project.com/FAQ:_Licensing#Why_does_Novell_require_(...)

Mes couilles oui !
Le PDF est pas plus ouvert que le sera le format Metro de MS.

bah c'est leur spécialité les listes, alors si quand ils envoient un mails ils en recoivent 100 automatiquement ou qu'il y a une tentative de DOS sur leurs serveurs web, tu penses bien que c'est dans leur intérêt d'épurer leurs listes d'adresses emails...

Dans la pratique si la FSF a une partie du copyright cela suffit pour qu'elle défende le code concerné. De plus les gens sont plus à même de refiler après coup leur copyright quand il s'agit de garantir et défendre leurs intérêts. Il faut être naïf pour croire que le cession de droit à la FSF ne sert qu'à cela.

Le problème c'est que ce standard n'impose pas de fonctionnalités "standard" dans les suites concernées, et même si c'est le même format de fichier (c'est déjà un grand pas en avant), faut pas rêver, ca ne sera pas si simple que cela de passer d'un soft à l'autre... il y aura toujours des trucs supportés que par tel ou tel soft, tel ou tel soft qui interprête différement le standard, etc.

Si les gens veulent échanger un document sans le modifier ils se pencheront plutôt du côté des formats ala PDF, et de ce côté MS veut imposer son standard (Metro). On ne peut rien lui reprocher car il n'existe à l'heure actuelle aucun standard normalisé (PDF étant "standardisé" par Adobe).

Alors avant de crier victoire, on pourra facilement échanger nos documents quand on aura un standard d'édition (c'est le cas avec OpenDocument) ET un format de document pour consultation/impression.

C'est pas très dur de configurer un truc anti-spam pour renvoyer un message automatique... les spammeurs sauront non seulement que leurs mails ne sont pas lus, mais qu'en plus ils ne risquent pas de le faire (les utilisateurs concernés ayant installé un système anti-spam). Donc j'arrive à la conclusion inverse de toi : tu risques d'être "blacklister" chez les spammeurs, étant un client sans intérêt.

si ils le changent (surtout la FSF) c'est un coup de poignard dans le dos.
Fallait peut être t'interroger sur le pourquoi de leur demande de renonciation de tes droits... A part faciliter les changements de licence je vois pas trop...
Enfin comme tu le fais bien remarqué, le projet Classpath est sous une GPL "modifiée", qui semble plutôt correspondre à une (L)GPL.
Reste à savoir si Apache va considérer que c'est parfaitement compatible avec leur licence et donc si c'est réutilisable.
Enfin faut que les 2 parties s'entendent cordialement, du moment qu'ils ne font pas la connerie de repartir de 0...