From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id B81757F2AA for ; Fri, 21 Dec 2012 17:40:09 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=209.85.210.181; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of agarwal1975@gmail.com designates 209.85.210.181 as permitted sender) identity=mailfrom; client-ip=209.85.210.181; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ia0-f181.google.com) identity=helo; client-ip=209.85.210.181; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-ia0-f181.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIBAJ6P1FDRVdK1m2dsb2JhbABFtGYBiQ0IFg4BAQEBAQgJCwkUJ4IeAQEEAUABGx0BAwELBgULIwEXIQEBEQEFARwGExuHZQEDCQYMl0SMM4J7hREKGScNWYh2AQUMi2FqgRYBgywDiGKLU4FWgRyKGwKDLxYphDOBSAcX X-IronPort-AV: E=Sophos;i="4.84,330,1355094000"; d="scan'208";a="166562900" Received: from mail-ia0-f181.google.com ([209.85.210.181]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Dec 2012 17:40:08 +0100 Received: by mail-ia0-f181.google.com with SMTP id s32so4014959iak.26 for ; Fri, 21 Dec 2012 08:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Iq+qZCem8x1Pz/QsjL0IXm/CNy0v7lK2pAFoRH7CbXc=; b=UprFH0QGzjpLzZyoY17Rvlz7J2qOm6sUkhDL1GBlCjswl9vxqSGHPguzxJjrb7keZu PpTJJzEfRmfUDp21/s7S/H/f3a5hU+xjgZkhgsyDIfpVplyN6sr2RkH0SbjH29q8YBye zhMNiHiicMEE7SJOI7g7NYVu8jLjBiRP2stHEKDEGapdXZZyG0oaf0hBi6GFgQhK/pll ynDVMOZTOaEm2fs9DjALNn8TcTL+yLwZwfk+1UVIKN2Nw/f4FMQeGyYNrAwXiv537hL3 6y6iPrKWzq6sap+0arkm6xFJwJLBzBgLYSPs8gz0/44MvMFiSe0SGo+ygYtnSi+HK+Lx uXiQ== Received: by 10.50.77.133 with SMTP id s5mr9292595igw.110.1356108006913; Fri, 21 Dec 2012 08:40:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.47.229 with HTTP; Fri, 21 Dec 2012 08:39:45 -0800 (PST) In-Reply-To: References: <6A2113E2-2202-46EA-B0B0-7C80AA25B480@recoil.org> <88F05F0A-10A2-47AF-8285-575E95797E54@recoil.org> From: Ashish Agarwal Date: Fri, 21 Dec 2012 11:39:45 -0500 Message-ID: To: Wojciech Meyer Cc: Caml List Content-Type: multipart/alternative; boundary=e89a8f3bb0270776d904d15f8050 Subject: Re: [Caml-list] OCaml wiki --e89a8f3bb0270776d904d15f8050 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 21, 2012 at 8:05 AM, Wojciech Meyer wrote: The bottleneck I see that the changes needs to be "formally approved" > This is currently required because the ocaml.org repo contains code, which is run hourly on a server (formerly at OCamlPro, now at NYU, soon at OCaml Labs). Giving too many people direct push permission would be a security risk. Nonetheless, this can easily be resolved. We can have a separate repo for pure text contributions, and the ocaml.org code could pull from that one at publish time. My answer would be as lightweight as possible, oddmuse is perl, mediawiki > is php. > I'd go even lighter. So far the idea I like best is using github. We could create a new repo ocaml.org-wiki, in which we use just the wiki feature. This provides pure text files which can be manipulated to generate nice output however we want. We can give push permission to everyone who requests it. Before committing to this, I'd like to know if something like 99 Problems (solved) in OCaml could be supportable in a wiki (not just in theory, but realistically what work does it take)? Note it has images, icons to indicate the difficulty level, code that is auto-run through OCaml's toploop library, clickable boxes that show/hide the solution, and an auto-generated table of contents. All of these little details add up to making the page nice. A plain text version of this would be lame. Ideally, the tutorials, which are currently plain text, could also include more rich content like this. > Also these are wiki engines, so we probably don't need to hack on it. > Various hacking ends up being required. If you want to style the wiki content, you might have to change the attributes on the html elements, or something. Maybe someday we want to ocaml.org to have user accounts for some other reason, and at that point it would be nice to make the wiki login system integrate with these other services. Maybe the wiki has an SSO capability that works perfectly, but maybe you end up having to read php code. So no need to worry that we need to get dirty with php :) > It does scare me! > I also think ocsigen with ocsimore would be cool to have at some point I'm enticed by this a lot! The trick is to start this on some sub-component of the website without disrupting the current work flow. Pick a particular feature that would benefit from the rich dynamic capabilities ocsigen enables, implement that in a separate repo, show the code works, is maintainable, and then it can be integrated into ocaml.org. We could have at least a static webpage generator like Stog > That's what we have, but we are using Christophe Troestler's Weberizer. We should keep in mind all of the above is asking a lot from various people. Having an ocsigen backend means we are asking OCaml Labs to provide a server with ocsigen installed. Using the github wiki syntax to html converter, or weberizer, or stog means asking their respective authors to do work when the tools don't do exactly what is needed. Converting the current tutorials to wiki syntax will take hours, after hours were already spent converting them into html. But hey... a little peer pressure to get a better website is worth it. :) --e89a8f3bb0270776d904d15f8050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Dec 21, 2012 at 8:05 AM, Wojciech Meyer <wojciech.meyer@gma= il.com> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> The bottleneck I see that the changes needs to be "formally approved&q= uot;

This is currently required because= the ocaml.org repo contains code, which i= s run hourly on a server (formerly at OCamlPro, now at NYU, soon at OCaml L= abs). Giving too many people direct push permission would be a security ris= k.=A0Nonetheless, this can easily be resolved. We can have a separate repo = for pure text contributions, and the ocaml.org= code could pull from that one at publish time.


My answer woul= d be as lightweight as possible, oddmuse is perl,=A0mediawiki is php.

I'd go even lighter. So far the idea I= like best is using github. We could create a new repo ocaml.org-wiki, in w= hich we use just the wiki feature. This provides pure text files which can = be manipulated to generate nice output however we want. We can give push pe= rmission to everyone who requests it.

Before committing to this, I'd like to know if=A0so= mething like 99 Prob= lems (solved) in OCaml=A0could be supportable in a wiki (not just in th= eory, but realistically what work does it take)? Note it has images, icons = to indicate the difficulty level, code that is auto-run through OCaml's= toploop library, clickable boxes that show/hide the solution, and an auto-= generated table of contents. All of these little details add up to making t= he page nice. A plain text version of this would be lame. Ideally, the tuto= rials, which are currently plain text, could also include more rich content= like this.

=A0
Also these are = wiki engines, so we probably don't need to hack on it.
=

Various hacking ends up being required. If you want to style= the wiki content, you might have to change the attributes on the html elem= ents, or something. Maybe someday we want to o= caml.org to have user accounts for some other reason, and at that point= it would be nice to make the wiki login system integrate with these other = services. Maybe the wiki has an SSO capability that works perfectly, but ma= ybe you end up having to read php code.


So no need to = worry that we need to get dirty with php :)

It does scare me!

=A0
I also think ocsigen with ocsimore would be cool to have at some=A0point

I'm enticed by this a lot! The trick= is to start this on some sub-component of the website without disrupting t= he current work flow. Pick a particular feature that would benefit from the= rich dynamic capabilities ocsigen enables, implement that in a separate re= po, show the code works, is maintainable, and then it can be integrated int= o ocaml.org.


We could have at least a static webpage generator like Stog
=

That's what we have, but we are using Christophe Tr= oestler's Weberizer.

We should keep in mind al= l of the above is asking a lot from various people. Having an ocsigen backe= nd means we are asking OCaml Labs to provide a server with ocsigen installe= d. Using the github wiki syntax to html converter, or weberizer, or stog me= ans asking their respective authors to do work when the tools don't do = exactly what is needed. Converting the current tutorials to wiki syntax wil= l take hours, after hours were already spent converting them into html. But= hey... a little peer pressure to get a better website is worth it. =A0:)


--e89a8f3bb0270776d904d15f8050--