A new web newsreader

Vladimir Panteleev vladimir at thecybershadow.net
Fri Dec 9 09:03:23 PST 2011


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.


More information about the Digitalmars-d mailing list