On Tue, 18 Nov 2014 18:25:20 GMT, Sönke Ludwig wrote:
My idea was to use the same integrated serving as for http://vibed.org/api/. One advantage this would have is that it is much less expensive in terms of disk space and I/O, as well as in general preprocessing time. The full API documentation for vibe.d for example takes something around 2500 files in 30MB, so this could get costly pretty quick.
Ok, I see. It was the disk space I was most worried about, hence the "realistic" part in my original post.
If we compare code.dlang.org with rubygems.org, rubugems has 5822 packages and Dub has 369 packages. You say vibe.d is around 2500 files, I would guess that mosts projects is noway near that amount of files. But if we take that as an example, 5822 packages multiplied with 30 MB gives under 180 GB. In my opinion that's nothing in todays hard drives which have capacity of several terabytes. Although, of course I'm not expecting you to pay for this, you're already doing a great work with vibe.d and Dub :). BTW, if you serialize the AST to disk, won't that have the same problem as the pre-generated documentation in regards of disk space.
About the I/O, in my experience serving static pages are almost always faster than dynamically generated pages.
I'm not I understand the issue with preprocessing time. Won't your solution need to be processed basically on all requests compared to my solution which is once per package and version?
/Jacob Carlborg