<div>Matthew is taking the initiative here, so if he is fine with</div><div>sourceforge, then I'm OK with going back to it. It does seem that a</div><div>unified service will have the lightest administrative load. As to the</div>
<div>cost, I currently pay about $450/yr for the <a href="http://mlton.org">mlton.org</a> linux vps, and </div><div>Reactive at least sounds willing to contribute some. So, I don't think </div><div>we should feel pressured to go for a free solution if an inexpensive</div>
<div>(hundreds of dollars per year) paid solution will make users' and</div><div>administrators' lives better. I'm not actually suggesting one, just</div><div>making sure that we're not ruling something out for financial reasons.</div>
<div><br></div><div>As to web site, I do think it's essential that people can type</div><div><a href="http://mlton.org">mlton.org</a> into their browsers and get to the right place, and very</div><div>nice if <a href="http://mlton.org">mlton.org</a> can continue to appear in the web site as they</div>
<div>browse. IIRC sourceforge even supported tricks to do this 8 years ago</div><div>when we used them, so I would guess they do now too.</div><div><br></div><div>As to web content, I think a static site is completely fine for MLton.</div>
<div><br></div><div>As to source code, we should initially transition using svn, but I'd</div><div>advice keeping the ability to switch to something more modern (hg,</div><div>git, ...) eventually.</div><div><br></div>
<div>Whenever you want to move, just let me know. I'm happy to make</div><div>whatever DNS changes are necessary (I have <a href="http://mlton.org">mlton.org</a> registered</div><div>through godaddy).</div><div><br>
</div>
<br><div class="gmail_quote">On Wed, Jun 1, 2011 at 5:38 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've continued to research alternative hosting solutions for the<br>
<a href="http://mlton.org" target="_blank">mlton.org</a> content. My preference is still to migrate back to<br>
SourceForge.net. I've done some preliminary work and experiments, and<br>
I think that most of the transition would be straightforward.<br>
<br>
There were some concerns about SourceForge being "slow". My<br>
experiments show that it is actually faster than the current <a href="http://mlton.org" target="_blank">mlton.org</a><br>
hosting provider. Here are three experiments:<br>
<br>
1) I exported the MLton Subversion repository and imported it into<br>
<a href="http://mlton.svn.sourceforge.net" target="_blank">mlton.svn.sourceforge.net</a>. I performed a "/usr/bin/time svn checkout"<br>
of mlton/trunk@HEAD from both, with the following results over five<br>
trials:<br>
<br>
<a href="http://mlton.org" target="_blank">mlton.org</a>:<br>
54.62 real 1.41 user 2.62 sys<br>
67.31 real 1.41 user 2.62 sys<br>
47.28 real 1.41 user 2.64 sys<br>
42.38 real 1.40 user 2.60 sys<br>
52.38 real 1.41 user 2.61 sys<br>
<a href="http://mlton.svn.sourceforge.net" target="_blank">mlton.svn.sourceforge.net</a>:<br>
18.18 real 1.86 user 2.59 sys<br>
19.40 real 1.87 user 2.61 sys<br>
20.37 real 1.86 user 2.61 sys<br>
19.45 real 1.87 user 2.58 sys<br>
20.33 real 1.87 user 2.54 sys<br>
<br>
So, the slowest SourceForge checkout is half the time of the fastest<br>
<a href="http://mlton.org" target="_blank">mlton.org</a> checkout.<br>
<br>
2) I copied the mlton-svnroot.tar.bz2 file (48M) to<br>
<a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a>. I performed a "/usr/bin/time wget" of the file<br>
from both, with the following results:<br>
<br>
<a href="http://mlton.org" target="_blank">mlton.org</a> (one large):<br>
40.98 real 0.11 user 0.80 sys<br>
41.50 real 0.11 user 0.79 sys<br>
40.33 real 0.10 user 0.79 sys<br>
40.98 real 0.11 user 0.79 sys<br>
41.48 real 0.11 user 0.81 sys<br>
<a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a> (one large):<br>
41.19 real 0.06 user 0.68 sys<br>
42.30 real 0.06 user 0.68 sys<br>
40.84 real 0.05 user 0.57 sys<br>
40.78 real 0.06 user 0.61 sys<br>
42.21 real 0.06 user 0.63 sys<br>
<br>
So, nearly identical performance for downloading one large file,<br>
indicating that the bandwidth for web content is about the same.<br>
<br>
3) I copied the guide/ directory from <a href="http://mlton.org" target="_blank">mlton.org</a> to<br>
<a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a>. These are static HTML snapshots of the wiki<br>
from the past three releases (plus corresponding .tar.gz files),<br>
totaling 7.4M over 401 files. I performed a "/usr/bin/time wget -r<br>
-np -l inf" of this directory from both, with the following results:<br>
<br>
<a href="http://mlton.org" target="_blank">mlton.org</a> (many small):<br>
39.50 real 0.12 user 0.27 sys<br>
40.67 real 0.12 user 0.27 sys<br>
41.05 real 0.12 user 0.27 sys<br>
41.20 real 0.12 user 0.27 sys<br>
41.12 real 0.12 user 0.28 sys<br>
<a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a> (many small):<br>
17.56 real 0.12 user 0.21 sys<br>
20.64 real 0.11 user 0.20 sys<br>
16.87 real 0.12 user 0.20 sys<br>
15.92 real 0.11 user 0.20 sys<br>
15.99 real 0.11 user 0.20 sys<br>
<br>
So, the slowest SourceForge fetch is about half the fastest <a href="http://mlton.org" target="_blank">mlton.org</a><br>
fetch, indicating that the latency for web content is much better on<br>
SF.<br>
<br>
Of course, what that doesn't test is speed of dynamic content<br>
generation, which might or might not be important. Currently, all of<br>
the wiki content of <a href="http://mlton.org" target="_blank">mlton.org</a> is dynamic content, but it isn't clear<br>
that it would be easy or worthwhile to install MoinMoin on MLton's<br>
SourceForge project web.<br>
<br>
<br>
The mlton-{devel,<a href="mailto:user%7D@lists.sourceforge.net">user}@lists.sourceforge.net</a> mailing lists still<br>
exist, though had been purged of subscribers. I worked through all of<br>
the MailMan admin screens and configured them to reject all spam (as<br>
identified by the SourceForge.net spam filters), to hold all<br>
non-subscriber posts for moderation, to accept all subscriber posts,<br>
and to admin approve subscription requests. [There are also<br>
mlton-{announce,<a href="mailto:commit%7D@lists.sourceforge.net">commit}@lists.sourceforge.net</a> mailing lists,<br>
configured as read-only.] As I mentioned previously, I think that<br>
this is the simplest configuration. Certainly simpler than the<br>
configuration currently on <a href="http://mlton.org" target="_blank">mlton.org</a>, with its whitelist and no<br>
automatic spam filtering. As I noted previously, we can also import<br>
our existing archives, although they end up not as pipermail archives,<br>
but as SF's "forum archives" [which I admit are significantly less<br>
navigable than the pipermail archives]. It is also trivially to copy<br>
our existing pipermail archives (they are just static web content)<br>
over to <a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a>. In a perfect world, it would be nice<br>
to continue to add new messages to the pipermail archives. Since one<br>
can access the mbox archives of SF mailing lists for backup purposes,<br>
it might be possible to do so, though non-trivial as pipermail seems<br>
to be fairly tightly integrated with mailman.<br>
<br>
<br>
That leaves the wiki content. As noted before, SF provides MediaWiki,<br>
but at a rather deeper URL than just <a href="http://mlton.sourceforge.net" target="_blank">mlton.sourceforge.net</a>. Also, as<br>
noted before, we would lose many of our wiki macros for pulling in<br>
content directly from the Subversion repository. Also, we would lose<br>
syntax highlighting of SML code (whether directly in the page or<br>
pulled from the Subversion repository).<br>
<br>
One option is to move to a completely static site via a static site<br>
generator. There seem to be quite a number of tools for generating<br>
HTML from simplified markup. I don't imagine that it would be too<br>
difficult to migrate the MoinMoin markup to a different markup.<br>
Ideally, we would use a tool that could be extended with analogs of<br>
our existing wiki macros and could make use of highlighting of SML<br>
code (i.e., using enscript or Pygments). My "vision" would be to<br>
place the markup pages plus any plugins/extensions to the base tool<br>
under version control, which would ensure that anyone could rebuild<br>
the site. Updating the web content from the version control content<br>
would be a nightly cron job (or possibly triggered by commits).<br>
<br>
<br>
Those are my thoughts. Migrating the Subversion repository is very<br>
quick (a couple of hours). Migrating the mailing lists would be a<br>
couple of days: freezing the lists; requesting the import of mbox<br>
archives; allowing @<a href="http://mlton.org" target="_blank">mlton.org</a> MX record to propagate through DNS.<br>
Migrating the web content would be quick (once there existed a means<br>
to generate the web content), plus the time to allow *.<a href="http://mlton.org" target="_blank">mlton.org</a> CNAME<br>
records to propagate through DNS.<br>
<br>
_______________________________________________<br>
MLton mailing list<br>
<a href="mailto:MLton@mlton.org">MLton@mlton.org</a><br>
<a href="http://mlton.org/mailman/listinfo/mlton" target="_blank">http://mlton.org/mailman/listinfo/mlton</a><br>
</blockquote></div><br>