A new web newsreader

[Andrei Alexandrescu]

On 12/9/11 9:39 AM, Vladimir Panteleev wrote:
> On Friday, 9 December 2011 at 15:15:05 UTC, Andrei Alexandrescu wrote:
>> It's news to me that opting for subdomains vs. directories introduces
>> significant differences in speed. Why?
>
> A domain or subdomain simply points at the server to which the request
> should go - so, once the (sub)domain name is resolved to an IP address,
> the requests go directly to the application.
>
> Assuming I continue running the program on my server, the only way to
> have the program appear under a subdirectory is to make the main website
> work as a proxy for all requests going to URLs in that "directory". This
> means that all data has to go to through the main website's server.

I see, thanks.

>> There's also dlang.org. So in order to introduce new domains or do
>> domain operations I need to talk to:
>>
>> 1. Jan Knepper who manages d-programming-language.org
>>
>> 2. Brad Roberts who manages d-p-l.org
>>
>> 3. Oscar Brynolf who owns dlang.org (and whom I don't know)
>>
>> I can do this, but it's slow, suboptimal, and involves dependencies
>> out of my control.
>
> So you'd like to create subdomains for all domains that lead to the
> website? I don't see why the necessity, other than to help the
> occasional person who doesn't remember which domain name we use for the
> forum subdomain. Note that if you're interested in aliases, they should
> be redirects, not mirrors (like d-p-l.org and unlike dlang.org).

Great. So we'd only have one domain a la forum.d-programming-language.org.

>> Interesting. I don't understand the security issues involved and why
>> they can't be addressed by the application, but you're the doc.
>> Perhaps we could hardcode only one domain there instead of allowing
>> attachments.xxx.org for three domains.
>
> The short version is that HTML attachments may contain malicious
> JavaScript code, which will have access to all forum cookies. For
> example, it would be possible to write a worm which would repost itself
> whenever anyone opened the attachment.

Interesting, thanks.

>> Sounds good. So, say I change doc.ddoc and/or style.css. What is the
>> flow through which those will be reflected on your end?
>
> I'm thinking about a script that will download the files from the main
> website, apply whatever patches are necessary, and makes them live. I'm
> going to have a look at reducing the number of changes to minimum.
> Perhaps with a few changes on d-p-l.org's side, we can avoid any
> patching entirely.
>
>> What would the URLs for posts look like?
>
> url = site-root "/post/" stripped-message-id
>
> site-root is currently
> "http://dfeed.kimsufi.thecybershadow.net/discussion".
>
> stripped-message-id is the Message ID as it appears in the message
> headers, stripped of the terminal angle brackets, and with special
> characters percent-encoded using usual URL escape rules.
>
> So, for example with the new domain idea, the URL to your post would be:
>
> http://dpl-forum.net/post/jbt8lp$1v37$1@digitalmars.com

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. 
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. 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.

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. 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.

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.


Andrei