On Friday, 9 December 2011 at 16:38:01 UTC, Andrei Alexandrescu
wrote:
I think the domain dfeed.kimsufi.thecybershadow.net should be
completely invisible to people who browse the news, google,
etc. When googling for posts one should /only/ find
forum.d-programming-language.org/xxx URLs.
Absolutely. As I stated in the OP, the current address is
temporary. I'll change it to a redirect after we create the
official one.
I hope you don't take this the wrong way, but (a) I think
having posts under that master domain looks integrated and
professional, (b) if you later get hit by a bus or simply move
on to other interests the domain doesn't go dark.
I'm all for this (which is also why I'm for providing shell
access to D VIPs).
The second point also raises questions such as who owns the
user database etc. Long-term I don't think it's reasonable (and
I don't think you want!) to keep user account information on
your own server for all installations of dfeed.
I'm not sure what you mean by "all installations of dfeed", and
how that affects where data is stored. Since I use SQLite, data
is in a file on the filesystem.
On the other hand, I don't want this "invisibility" to affect
negatively letting others know about your product. You should
put a notice in e.g. the footer a la "Page generated by dfeed",
with a link to the product.
The page accessible via the "Help" link has an "About" section.
I suggest you package your code in ways that make it easy to
deploy to any other website.
This all leads to the idea that at best you should package
dfeed as a classic "product" that you offer via github as an
independent project, with releases, updates, bug fixes, and the
such. Whenever you update the product you notify your clients
that they can update their installations through a classic
process (running a script etc). The disadvantage is that
clients would run the binaries which means more deployment
issues and the such. Also, given that dfeed does quite a few
more things than just bridging with NNTP you'd need to do some
serious work on packaging.
This goes a bit beyond the project's initial scope, since all I
wanted was to create something for D... There would be a good
amount of work involved in refactoring it in such a way so that
it could be easily set up and used for other projects. It would
be much easier if the need appeared before this work is started,
so that there would be a clear goal for what needs to be
modularized, configurable and customizable.
Please advise on how to best proceed in the short and long
term. I think in the short term we can run off your domain
(with the visible URLs using top domain
d-programming-language.org), and migrate later to a classic
product installation configuration that will preserve the URLs.
Sorry, I'm not following you again. Perhaps there was a
misunderstanding regarding how much the program is tied to my
server? As it is, all data (newsgroup/mailing list posts, users
and user preferences) are stored in a single SQLite database
file. Assuming all necessary build tools (of which only D is a
requirement) are present, the program otherwise has no other
dependencies - it doesn't even need a separate web server (like
Apache). So, other users of the program would run it on their own
server, and have their own database of everything on their
server's filesystem.
