• Vladimir Panteleev (66/66) Dec 08 2011 As mentioned previously, I've been working on a web frontend for the
• Jakob Ovrum (12/12) Dec 08 2011 Great work, been using it for the past few days, and I'm
• Dejan Lekic (4/6) Dec 08 2011 Considering the fact that this interface is far superior to the
• Dmitry (4/7) Dec 08 2011 It would be great to have a button "View New Posts". It could be
• Vladimir Panteleev (2/4) Dec 08 2011 What would such a button do?
• Dmitry (32/36) Dec 08 2011 It would allow you to view all of the topics which have new
• Vladimir Panteleev (4/12) Dec 08 2011 Sounds good. I think we could also create a front page that's
• SomeDude (2/7) Dec 08 2011 Super cool !!
• so (5/6) Dec 08 2011 Awesome work! Seriously, vim keys?!
• Vladimir Panteleev (5/7) Dec 08 2011 How would a refresh feature work, and be better than just hitting
• so (3/6) Dec 08 2011 Oh you are right, i forgot it was a "web" newsreader. Sorry :)
• SomeDude (7/82) Dec 08 2011 BTW, on Firefox 3.6.24, it says that pushState is not supported,
• Vladimir Panteleev (8/15) Dec 08 2011 While basic functionality might work, it will still generate and
• Steven Schveighoffer (9/84) Dec 08 2011 you receive an A+ from me!
• Vladimir Panteleev (18/22) Dec 08 2011 Thanks :) The reason why I chose to sort by older posts first is
• Steven Schveighoffer (17/37) Dec 08 2011 Having the newest post at the bottom of the top-most group is acceptable...
• Vladimir Panteleev (14/23) Dec 08 2011 JavaScript which alters page content on load is bad, because by
• Steven Schveighoffer (4/7) Dec 08 2011 The new version is perfect, thanks!
• tn (6/21) Dec 08 2011 In that case also paging should follow the same rule. That is,
• Vladimir Panteleev (9/22) Dec 08 2011 I think that would be even more confusing.
• Jeff Nowakowski (3/4) Dec 08 2011 Replies to posts should follow convention and prefix the subject with
• Dejan Lekic (2/2) Dec 08 2011 On a mailing list yes. However, on the newsgroup it is IMHO
• Vladimir Panteleev (3/8) Dec 08 2011 That was a bug I fixed shortly after the announcement.
• Jonas Drewsen (9/15) Dec 08 2011 This is very nice work. I may actually be able to replace my thunderbird...
• Robert Clipsham (17/30) Dec 08 2011 Oooh, it's almost ready enough to let me replace my Thunderbird usage!
• Robert Clipsham (6/39) Dec 08 2011 Another one - log in using OpenID so I don't have to remember another
• Andrej Mitrovic (10/10) Dec 08 2011 Such a sexy NG interface! The only thing missing is ability to quickly
• Walter Bright (3/6) Dec 08 2011 Yes! I also think this forum software will be highly desirable for other...
• Vladimir Panteleev (20/33) Dec 08 2011 I'm not very excited about the idea of introducing formatting
• Jacob Carlborg (5/12) Dec 08 2011 It might be possible using the right combination of layers and absolute
• Vladimir Panteleev (5/21) Dec 08 2011 You still need to change from normal to fixed positioning when
• Jacob Carlborg (4/20) Dec 08 2011 Yeah, I guess so.
• Robert Clipsham (21/51) Dec 08 2011 I've seen quite a few people using it for code snippets anyway, and it's...
• Walter Bright (2/11) Dec 08 2011 I agree to not do this.
• maarten van damme (3/3) Dec 08 2011 Beautiful newsgroup reader, makes a forum obselute but I am against maki...
• Jesse Phillips (6/16) Dec 09 2011 You do realize that > is a formatting feature, and like ---- it
• Vladimir Panteleev (4/8) Dec 09 2011 Using ">" for quotes is a widely-implemented standard (see e.g.
• jdrewsen (6/14) Dec 10 2011 How do you feel about creating a setting that would make ----
• Jacob Carlborg (8/14) Dec 08 2011 Very nice. Although I would hope for a version that would work better in...
• Vladimir Panteleev (6/11) Dec 08 2011 The "threaded" view mode should look the best on small screens.
• Andrei Alexandrescu (3/13) Dec 08 2011 How do they switch from column layout to no-column layout on tight width...
• Vladimir Panteleev (4/17) Dec 08 2011 There is a CSS rule which sets the divs (which are normally at
• Jacob Carlborg (6/16) Dec 08 2011 Yes, but try adding the following meta tag:
• Vladimir Panteleev (3/9) Dec 08 2011 OK, how does it look now?
• Jacob Carlborg (6/16) Dec 08 2011 Horribly broken, sorry, remove it. I was hoping the above would be a
• Vladimir Panteleev (4/24) Dec 08 2011 OK. I don't have a smartphone, but if I get the chance I'll have
• Jacob Carlborg (5/24) Dec 08 2011 You can download a simulator, from the Android SDK or the iOS SDK. The
• Walter Bright (3/7) Dec 08 2011 I am very excited, this is freakin' awesome!
• Vladimir Panteleev (4/6) Dec 08 2011 In a table in an SQLite database. Passwords are stored as salted
• Andrei Alexandrescu (42/48) Dec 08 2011 This is an absolutely fantastic development. It's exactly the kind of
• Andrei Alexandrescu (6/16) Dec 08 2011 One more thing:
• Jacob Carlborg (7/32) Dec 08 2011 Perhaps as a git submodule in d-programming-language.org? Dfeed would
• Steven Schveighoffer (10/15) Dec 08 2011 Hm... I don't understand the objection to having the project live on its...
• Vladimir Panteleev (58/108) Dec 08 2011 I'm excited :)
• Andrei Alexandrescu (17/45) Dec 09 2011 Essentially I'm looking at achieving a streamlined process that would
• Vladimir Panteleev (37/53) Dec 09 2011 We need to decide on one URL structure and stick to it. Breaking
• Andrei Alexandrescu (22/53) Dec 09 2011 It's news to me that opting for subdomains vs. directories introduces
• Adam D. Ruppe (12/15) Dec 09 2011 Separate domains are a defense-in-depth kind of thing. The browser
• Vladimir Panteleev (35/51) Dec 09 2011 A domain or subdomain simply points at the server to which the
• Andrei Alexandrescu (32/82) Dec 09 2011 Great. So we'd only have one domain a la forum.d-programming-language.or...
• Vladimir Panteleev (28/61) Dec 09 2011 Absolutely. As I stated in the OP, the current address is
• Vladimir Panteleev (4/5) Dec 09 2011 OK, that's a lie. It obviously needs SQLite, and it also uses
• Andrei Alexandrescu (20/40) Dec 09 2011 I understand. So you want to approach this by serving forum content off
• Vladimir Panteleev (10/25) Dec 09 2011 I must confess I have not considered for such a possibility. You
• Walter Bright (3/7) Dec 09 2011 I hadn't thought about that.
• Vladimir Panteleev (7/10) Dec 09 2011 What if someone with an NNTP client posts a question and attaches
• Walter Bright (6/14) Dec 09 2011 It's not the sole problem, I mentioned a couple other in another post.
• Vladimir Panteleev (6/11) Dec 09 2011 The problem is that they won't know that some users won't be able
• Walter Bright (3/8) Dec 09 2011 I don't know if that can be done - but it is configured to reject posts ...
• David Nadlinger (9/16) Dec 09 2011 This strikes me as overly complicated. Why aren't the alias domains just...
• Walter Bright (3/8) Dec 09 2011 Much as I like the voting system, I agree that it may be not worth it du...
• Walter Bright (7/12) Dec 09 2011 I recommend ignoring attachments, including HTML ones. The current D arc...
• Vladimir Panteleev (5/11) Dec 09 2011 I just realized I missed another simple option: an entirely new
• Andrei Alexandrescu (3/12) Dec 09 2011 At this point I'd say we have too many domains, not too few.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

As mentioned previously, I've been working on a web frontend for the  
DigitalMars NNTP server. I collected ideas and inspiration from the  
several threads on this topic in the last few weeks, and now I think that  
the result is ready for beta testing and general use.

The current (temporary) URL is:

http://dfeed.kimsufi.thecybershadow.net/discussion/

Here are the highlights:

* Written in D, pull requests are welcome.
   https://github.com/CyberShadow/DFeed

* It remembers which posts you've seen on an individual post basis.
   By default, read post history is stored in a compressed cookie.

* Optionally, you can register an account, which will store your  
preferences and read post history in the server database. There is no  
e-mail confirmation etc.

* You can choose any of three view modes:
   1) The default "basic" view, a forum-like view with paged linear threads  
(posts are chronologically-ordered).
   2) "Threaded", with threaded group index, and a thread overview under  
the single post display, similar to mailing list archives.
   3) "Horizontal-split" - a JavaScript-powered interface with a split view  
and keyboard shortcuts, similar to a mail or newsgroup client.

   There was also another view mode, "nested", which presented all messages  
in a thread in full, arranged in their hierarchical order (with replies  
being slightly indented from their parents). However, the idea is not  
compatible with paging and and it didn't look well at high nesting levels,  
so I removed it.

   For the sake of link consistency and preserving functionality of links  
between JavaScript and no-JavaScript users, the "horizontal-split" view  
mode requires support for the HTML5 history.pushState feature. This  
feature is present in all modern browsers except Internet Explorer.

* The URL scheme attempts to be simple and consistent. There is one way to  
link to an individual post: {site root}/post/{message-id stripped of angle  
brackets}. Post links will open in the user's selected view mode.

* Posted messages are screened for spam using several online services  
(incl. Akismet). A failed spam check, or an attempt to post within 1  
minute of another posting attempt, will trigger a CAPTCHA. Solving the  
CAPTCHA will bypass spam/flood checks (no messages will be silently  
discarded). The posting form should be protected against XSRF attacks.

* The posted message and quoted text formatters understand format=flowed  
and delsp=yes (RFC 2646, 3676). If all mail/news software did, there would  
be no problems with broken quote lines - I believe the current web  
interfaces on digitalmars.com are the most notorious offenders.

* Multipart messages and attachments are decoded and are viewable /  
downloadable, although there is currently no support for posting  
attachments.
   I have also added support for decoding inline uuencoded attachments,  
which can be often found in older posts.

* Page formatting is affected by the width of the browser window - in  
smaller viewports, the font becomes smaller and the left sidebar is hidden  
away. I don't expect this feature to be perfect due to the great variety  
of installed fonts, but I hope it will be helpful nevertheless.

* The web interface gets a perfect score of 100/100 on the Google Page  
Speed test, and generates valid HTML 4.01 Strict.

There are more ideas for possible future improvements (e.g. attachment  
posting support and full-text search), but I think these are beyond the  
scope of "version 1.0". I'm somewhat exhausted right now, and need to  
catch up on other projects, so, with your feedback, we can revisit future  
improvements a while later.

If there is interest to use DFeed as the main web interface (and thus make  
it available from a D-related domain), I think the best way to do this  
would be to redirect two subdomains to my server (a separate subdomain for  
attachments, for security). It would also be possible to replace the old  
web interfaces with working redirects to DFeed.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net

"Jakob Ovrum" <jakobovrum gmail.com> writes:

Great work, been using it for the past few days, and I'm 
extremely happy with it - thanks again! :)
Uses space very efficiently on my netbook - no need for a bulky 
mail client when on the move. For me, this was the biggest hurdle 
in the way of regularly reading the NG.
I also happen to be one of the people who prefer reading threads 
linearly in typical web forum fashion, and this interface gets it 
just right.
With a quality web bridge like this, there should be no need for 
a separate web forum community, which would be a disaster in 
terms of building a cohesive D community. I would definitely 
recommend promoting this interface on the official website.

"Dejan Lekic" <dejan.lekic gmail.com> writes:

 in terms of building a cohesive D community. I would definitely 
 recommend promoting this interface on the official website.

Considering the fact that this interface is far superior to the 
Web-News and phpNews I see no reason for leaving those old news 
interfaces. They should be completely removed, and this one 
should take their places.

"Dmitry" <kdmult ya.ru> writes:

Thanks so much, great work!

On 2011-Dec-08 10:55:51+00:00, Vladimir Panteleev wrote:
 There are more ideas for possible future improvements (e.g. 
 attachment posting support and full-text search), but I think 
 these are beyond the scope of "version 1.0".

It would be great to have a button "View New Posts". It could be 
very useful and I think it is only what we need actually. :)

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 11:43:25 UTC, Dmitry wrote:
 It would be great to have a button "View New Posts". It could 
 be very useful and I think it is only what we need actually. :)

What would such a button do?

"Dmitry" <kdmult ya.ru> writes:

On Thursday, 8 December 2011 at 13:19:39 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 8 December 2011 at 11:43:25 UTC, Dmitry wrote:
 It would be great to have a button "View New Posts". It could 
 be very useful and I think it is only what we need actually. :)

 What would such a button do?

It would allow you to view all of the topics which have new 
messages (replies) in since your last visit. Each the topic would 
contain the new messages only and, if it makes sense, the 
original messages too.

For example, assume that I had already read everything and 
replied to your message some time ago.
A few minutes later I had pressed button/link "View New Posts" on 
the "Forum Index" page so that there was your reply only.
The page could look as follows.

› Forum Index
======== D Programming Language ========
Forum              Last Post
----------------------------------------
digitalmars.D      A new web newsreader
                   by Vladimir Panteleev
                           ? minutes ago

The page would be empty at all, if there was nothing new for 
reading. Alternatively, another approach could keep it as it is 
for now, but indicate somehow on unread messages (e.g. change the 
font style or place a count of new messages).

Then, if I had entered to "digitalmars.D" with the new message 
the page could look as below.

› digitalmars.D
======= A new web newsreader ========
Dmitry                    ? hours ago // original message, had 
been already read
  Vladimir Panteleev    ? minutes ago // unread message

Sorry for unclear explanation.

In other words, button "View New Posts" could update a page 
filtering out all read messages.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 14:10:54 UTC, Dmitry wrote:
 It would allow you to view all of the topics which have new 
 messages (replies) in since your last visit. Each the topic 
 would contain the new messages only and, if it makes sense, the 
 original messages too.
 (...)
 Alternatively, another approach could keep it as it is for now, 
 but indicate somehow on unread messages (e.g. change the font 
 style or place a count of new messages).

Sounds good. I think we could also create a front page that's 
more useful than just a group list. It could contain information 
such as replies to your posts, "followed" threads, etc.

"SomeDude" <lovelydear mailmetrash.com> writes:

On 2011-Dec-08 10:55:51+00:00, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend 
 for the DigitalMars NNTP server. I collected ideas and 
 inspiration from the several threads on this topic in the last 
 few weeks, and now I think that the result is ready for beta 
 testing and general use.

Super cool !!

so <so so.so> writes:

On Thu, 08 Dec 2011 12:55:44 +0200, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 ...

Awesome work! Seriously, vim keys?!
Is it possible to add refresh and collapse for thread/threads view?
I might as well use it instead of opera now.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 12:12:15 UTC, so wrote:
 Is it possible to add refresh

How would a refresh feature work, and be better than just hitting 
F5?

 and collapse for thread/threads view?

I assume it should also remember the collapsed state of threads 
when you come back. It's something to think about.

so <so so.so> writes:

On Thu, 08 Dec 2011 14:57:40 +0200, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Thursday, 8 December 2011 at 12:12:15 UTC, so wrote:
 Is it possible to add refresh

 How would a refresh feature work, and be better than just hitting F5?

Oh you are right, i forgot it was a "web" newsreader. Sorry :)

"SomeDude" <lovelydear mailmetrash.com> writes:

On 2011-Dec-08 10:55:51+00:00, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend 
 for the DigitalMars NNTP server. I collected ideas and 
 inspiration from the several threads on this topic in the last 
 few weeks, and now I think that the result is ready for beta 
 testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

 Here are the highlights:

 * Written in D, pull requests are welcome.
  https://github.com/CyberShadow/DFeed

 * It remembers which posts you've seen on an individual post 
 basis.
  By default, read post history is stored in a compressed cookie.

 * Optionally, you can register an account, which will store 
 your preferences and read post history in the server database. 
 There is no e-mail confirmation etc.

 * You can choose any of three view modes:
  1) The default "basic" view, a forum-like view with paged 
 linear threads (posts are chronologically-ordered).
  2) "Threaded", with threaded group index, and a thread 
 overview under the single post display, similar to mailing list 
 archives.
  3) "Horizontal-split" - a JavaScript-powered interface with a 
 split view and keyboard shortcuts, similar to a mail or 
 newsgroup client.

  There was also another view mode, "nested", which presented 
 all messages in a thread in full, arranged in their 
 hierarchical order (with replies being slightly indented from 
 their parents). However, the idea is not compatible with paging 
 and and it didn't look well at high nesting levels, so I 
 removed it.

  For the sake of link consistency and preserving functionality 
 of links between JavaScript and no-JavaScript users, the 
 "horizontal-split" view mode requires support for the HTML5 
 history.pushState feature. This feature is present in all 
 modern browsers except Internet Explorer.

 * The URL scheme attempts to be simple and consistent. There is 
 one way to link to an individual post: {site 
 root}/post/{message-id stripped of angle brackets}. Post links 
 will open in the user's selected view mode.

 * Posted messages are screened for spam using several online 
 services (incl. Akismet). A failed spam check, or an attempt to 
 post within 1 minute of another posting attempt, will trigger a 
 CAPTCHA. Solving the CAPTCHA will bypass spam/flood checks (no 
 messages will be silently discarded). The posting form should 
 be protected against XSRF attacks.

 * The posted message and quoted text formatters understand 
 format=flowed and delsp=yes (RFC 2646, 3676). If all mail/news 
 software did, there would be no problems with broken quote 
 lines - I believe the current web interfaces on digitalmars.com 
 are the most notorious offenders.

 * Multipart messages and attachments are decoded and are 
 viewable / downloadable, although there is currently no support 
 for posting attachments.
  I have also added support for decoding inline uuencoded 
 attachments, which can be often found in older posts.

 * Page formatting is affected by the width of the browser 
 window - in smaller viewports, the font becomes smaller and the 
 left sidebar is hidden away. I don't expect this feature to be 
 perfect due to the great variety of installed fonts, but I hope 
 it will be helpful nevertheless.

 * The web interface gets a perfect score of 100/100 on the 
 Google Page Speed test, and generates valid HTML 4.01 Strict.

 There are more ideas for possible future improvements (e.g. 
 attachment posting support and full-text search), but I think 
 these are beyond the scope of "version 1.0". I'm somewhat 
 exhausted right now, and need to catch up on other projects, 
 so, with your feedback, we can revisit future improvements a 
 while later.

 If there is interest to use DFeed as the main web interface 
 (and thus make it available from a D-related domain), I think 
 the best way to do this would be to redirect two subdomains to 
 my server (a separate subdomain for attachments, for security). 
 It would also be possible to replace the old web interfaces 
 with working redirects to DFeed.

BTW, on Firefox 3.6.24, it says that pushState is not supported, 
nevertheless the horizontal-split works fine and I like it very 
much. I would like to be able to resize the left window, though, 
as with deeply nested dicussions, I'm affraid we might run out of 
space (although I haven't seen it in the last 40 pages or so of 
discussions).

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 12:16:21 UTC, SomeDude wrote:
 BTW, on Firefox 3.6.24, it says that pushState is not 
 supported, nevertheless the horizontal-split works fine and I 
 like it very much.

While basic functionality might work, it will still generate and 
send the entire threaded view for every click. That's a lot of 
wasted resources. I was going to remove the link entirely for 
unsupported browsers, but now I'm not sure what to do about it.

 I would like to be able to resize the left window, though, as 
 with deeply nested dicussions, I'm affraid we might run out of 
 space (although I haven't seen it in the last 40 pages or so of 
 discussions).

That's because the indentation is automatically adjusted based on 
the deepest reply level. At the worst, you could see line breaks 
in long names.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On 2011-Dec-08 10:55:51+00:00, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend 
 for the DigitalMars NNTP server. I collected ideas and 
 inspiration from the several threads on this topic in the last 
 few weeks, and now I think that the result is ready for beta 
 testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

 Here are the highlights:

 * Written in D, pull requests are welcome.
  https://github.com/CyberShadow/DFeed

 * It remembers which posts you've seen on an individual post 
 basis.
  By default, read post history is stored in a compressed cookie.

 * Optionally, you can register an account, which will store 
 your preferences and read post history in the server database. 
 There is no e-mail confirmation etc.

 * You can choose any of three view modes:
  1) The default "basic" view, a forum-like view with paged 
 linear threads (posts are chronologically-ordered).
  2) "Threaded", with threaded group index, and a thread 
 overview under the single post display, similar to mailing list 
 archives.
  3) "Horizontal-split" - a JavaScript-powered interface with a 
 split view and keyboard shortcuts, similar to a mail or 
 newsgroup client.

  There was also another view mode, "nested", which presented 
 all messages in a thread in full, arranged in their 
 hierarchical order (with replies being slightly indented from 
 their parents). However, the idea is not compatible with paging 
 and and it didn't look well at high nesting levels, so I 
 removed it.

  For the sake of link consistency and preserving functionality 
 of links between JavaScript and no-JavaScript users, the 
 "horizontal-split" view mode requires support for the HTML5 
 history.pushState feature. This feature is present in all 
 modern browsers except Internet Explorer.

 * The URL scheme attempts to be simple and consistent. There is 
 one way to link to an individual post: {site 
 root}/post/{message-id stripped of angle brackets}. Post links 
 will open in the user's selected view mode.

 * Posted messages are screened for spam using several online 
 services (incl. Akismet). A failed spam check, or an attempt to 
 post within 1 minute of another posting attempt, will trigger a 
 CAPTCHA. Solving the CAPTCHA will bypass spam/flood checks (no 
 messages will be silently discarded). The posting form should 
 be protected against XSRF attacks.

 * The posted message and quoted text formatters understand 
 format=flowed and delsp=yes (RFC 2646, 3676). If all mail/news 
 software did, there would be no problems with broken quote 
 lines - I believe the current web interfaces on digitalmars.com 
 are the most notorious offenders.

 * Multipart messages and attachments are decoded and are 
 viewable / downloadable, although there is currently no support 
 for posting attachments.
  I have also added support for decoding inline uuencoded 
 attachments, which can be often found in older posts.

 * Page formatting is affected by the width of the browser 
 window - in smaller viewports, the font becomes smaller and the 
 left sidebar is hidden away. I don't expect this feature to be 
 perfect due to the great variety of installed fonts, but I hope 
 it will be helpful nevertheless.

 * The web interface gets a perfect score of 100/100 on the 
 Google Page Speed test, and generates valid HTML 4.01 Strict.

 There are more ideas for possible future improvements (e.g. 
 attachment posting support and full-text search), but I think 
 these are beyond the scope of "version 1.0". I'm somewhat 
 exhausted right now, and need to catch up on other projects, 
 so, with your feedback, we can revisit future improvements a 
 while later.

 If there is interest to use DFeed as the main web interface 
 (and thus make it available from a D-related domain), I think 
 the best way to do this would be to redirect two subdomains to 
 my server (a separate subdomain for attachments, for security). 
 It would also be possible to replace the old web interfaces 
 with working redirects to DFeed.

you receive an A+ from me!

BTW, is there any way to sort the threaded view so that the 
newest messages appear on top?  Simply because, in a web page, 
the top is what shows up first.

The speed is incredible.  I'm used to webnews which takes several 
seconds to do its thing (not surprising, it's in php).

-Steve

(Posted from the new web interface).

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 12:27:44 UTC, Steven 
Schveighoffer wrote:
 you receive an A+ from me!

 BTW, is there any way to sort the threaded view so that the 
 newest messages appear on top?  Simply because, in a web page, 
 the top is what shows up first.

Thanks :) The reason why I chose to sort by older posts first is 
a bit convoluted:

Generally, in a threaded discussion, replies always have to 
appear below their parents. Even though it's possible to sort 
siblings in the reverse order, it would be rather inconsistent. 
The same goes with entire threads - the last post in a group will 
appear as the *bottom-most* child of its parent, inside the 
*topmost* thread.

This was not a problem for the split-view mode, because 
JavaScript scrolls down the message list when the page is loaded. 
I've finished the threaded view after the split-view, which 
inherited its order. I decided to leave it as it is for 
consistency with what the view was modelled after - mailing list 
archives.

I'm thinking that we could eventually have a "Preferences" page, 
where we could go nuts with options and customization.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 08 Dec 2011 08:13:36 -0500, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Thursday, 8 December 2011 at 12:27:44 UTC, Steven Schveighoffer wrote:
 you receive an A+ from me!

 BTW, is there any way to sort the threaded view so that the newest  
 messages appear on top?  Simply because, in a web page, the top is what  
 shows up first.

 Thanks :) The reason why I chose to sort by older posts first is a bit  
 convoluted:

 Generally, in a threaded discussion, replies always have to appear below  
 their parents. Even though it's possible to sort siblings in the reverse  
 order, it would be rather inconsistent. The same goes with entire  
 threads - the last post in a group will appear as the *bottom-most*  
 child of its parent, inside the *topmost* thread.

Having the newest post at the bottom of the top-most group is acceptable  
for a threaded view, simply because in a threaded view, that is the  
natural order.

But having the newest item near the bottom of the page makes it slightly  
annoying, since it isn't the focus when the page loads.

Would a simple "scroll to bottom on page load" in javascript be possible?   
I know there are some nicks on this newsgroup who don't like JS, but their  
browser simply won't scroll.  So what.

 This was not a problem for the split-view mode, because JavaScript  
 scrolls down the message list when the page is loaded. I've finished the  
 threaded view after the split-view, which inherited its order. I decided  
 to leave it as it is for consistency with what the view was modelled  
 after - mailing list archives.

I understand.  I'm just used to webnews which put the threads with the  
newest posts on top.  But I think a simliar javascript solution would be  
acceptable.

 I'm thinking that we could eventually have a "Preferences" page, where  
 we could go nuts with options and customization.

Probably, this is a cool project.  If I ever come across having to use  
forum software, I'm going to use it.

Now, you just need the management pages to administer a real forum :)

-Steve

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 13:23:53 UTC, Steven 
Schveighoffer wrote:
 Would a simple "scroll to bottom on page load" in javascript be 
 possible?  I know there are some nicks on this newsgroup who 
 don't like JS, but their browser simply won't scroll.  So what.

JavaScript which alters page content on load is bad, because by 
the time it executes you might have already started reading the 
page. I think it's best to avoid such nuisances.

 I understand.  I'm just used to webnews which put the threads 
 with the newest posts on top.

I think I'll just reverse the sorting of threads in the threaded 
view. Threads are already sorted differently than posts anyway 
(they're sorted by the time of the last reply, not by the 
original post's time).

 Probably, this is a cool project.  If I ever come across having 
 to use forum software, I'm going to use it.

The code would need a good refactoring to get the D hacks out. 
It's a bit of a mess in that regard.

 Now, you just need the management pages to administer a real 
 forum :)

Who says there isn't one?

https://github.com/CyberShadow/ae/blob/master/demo/sqlite/exec.d

;)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 08 Dec 2011 08:34:18 -0500, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 I think I'll just reverse the sorting of threads in the threaded view.  
 Threads are already sorted differently than posts anyway (they're sorted  
 by the time of the last reply, not by the original post's time).

The new version is perfect, thanks!

-Steve

"tn" <no email.com> writes:

On Thursday, 8 December 2011 at 13:13:38 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 8 December 2011 at 12:27:44 UTC, Steven 
 Schveighoffer wrote:
 you receive an A+ from me!

 BTW, is there any way to sort the threaded view so that the 
 newest messages appear on top?  Simply because, in a web page, 
 the top is what shows up first.

 Thanks :) The reason why I chose to sort by older posts first 
 is a bit convoluted:

 Generally, in a threaded discussion, replies always have to 
 appear below their parents. Even though it's possible to sort 
 siblings in the reverse order, it would be rather inconsistent. 
 The same goes with entire threads - the last post in a group 
 will appear as the *bottom-most* child of its parent, inside 
 the *topmost* thread.

In that case also paging should follow the same rule. That is, 
last thread should be at the bottom of the _last_ page. (And of 
course the last page should be viewed by default.) Now it is at 
the bottom of the first page which is not exactly very intuitive.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 15:27:27 UTC, tn wrote:
 On Thursday, 8 December 2011 at 13:13:38 UTC, Vladimir 
 Panteleev wrote:
 Generally, in a threaded discussion, replies always have to 
 appear below their parents. Even though it's possible to sort 
 siblings in the reverse order, it would be rather 
 inconsistent. The same goes with entire threads - the last 
 post in a group will appear as the *bottom-most* child of its 
 parent, inside the *topmost* thread.

 In that case also paging should follow the same rule. That is, 
 last thread should be at the bottom of the _last_ page. (And of 
 course the last page should be viewed by default.) Now it is at 
 the bottom of the first page which is not exactly very 
 intuitive.

I think that would be even more confusing.

For one, the default page would be the last page - makes sense 
from your perspective, but certainly unusual in the web 
discussion board context. For two, the first page in one view 
would be the last page in another view, and page numbers no 
longer refer to the same set of threads (at the same point in 
time). E.g.: "Where was that thread you mentioned?" - "Oh, on the 
second or third page or so."

Jeff Nowakowski <jeff dilacero.org> writes:

On 12/08/2011 07:27 AM, Steven Schveighoffer wrote:
 (Posted from the new web interface).

Replies to posts should follow convention and prefix the subject with 
"Re: " if it doesn't already have one.

"Dejan Lekic" <dejan.lekic gmail.com> writes:

On a mailing list yes. However, on the newsgroup it is IMHO 
totally redundant. A matter of taste I think...

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 15:23:20 UTC, Jeff Nowakowski 
wrote:
 On 12/08/2011 07:27 AM, Steven Schveighoffer wrote:
 (Posted from the new web interface).

 Replies to posts should follow convention and prefix the 
 subject with "Re: " if it doesn't already have one.

That was a bug I fixed shortly after the announcement.

Jonas Drewsen <jdrewsen nospam.com> writes:

On 08/12/11 11.55, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

This is very nice work. I may actually be able to replace my thunderbird 
and solve the problem with using multiply computers for reading and not 
having the post read state in sync.

On the knitpicking side: The layout could make better use of the 
screenspace I think. Since you written it in D made it public available 
I might just try to improve it (matter of taste I know).

It should definitely replace the existing web news reader.

/Jonas

Robert Clipsham <robert octarineparrot.com> writes:

On 08/12/2011 10:55, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:



 Here are the highlights:

 * Written in D, pull requests are welcome.
 https://github.com/CyberShadow/DFeed

 * It remembers which posts you've seen on an individual post basis.
 By default, read post history is stored in a compressed cookie.

 * Optionally, you can register an account, which will store your
 preferences and read post history in the server database. There is no
 e-mail confirmation etc.

Oooh, it's almost ready enough to let me replace my Thunderbird usage!

A couple of feature requests (some I've already mentioned on IRC):

  * Support syntax highlighting for blocks enclosed with --- like DDoc 
does, maybe other types of blocks too such as {{{}}} that trac uses, or 
whatever github uses.
  * Does the mailing list have the same restriction as gmane has (no 
posting)?
  * Thundrbird has a "mark read" function for 
threads/messages/newsgroups - that'd be really useful.
  * In the horizontal-split view if you scroll down too far in the 
thread you can't see the current thread title, it would be good to make 
that sticky until you reach the next thread so you can see where you're 
up to



-- 
Robert
http://octarineparrot.com/

Robert Clipsham <robert octarineparrot.com> writes:

On 08/12/2011 13:51, Robert Clipsham wrote:
 On 08/12/2011 10:55, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:



 Here are the highlights:

 * Written in D, pull requests are welcome.
 https://github.com/CyberShadow/DFeed

 * It remembers which posts you've seen on an individual post basis.
 By default, read post history is stored in a compressed cookie.

 * Optionally, you can register an account, which will store your
 preferences and read post history in the server database. There is no
 e-mail confirmation etc.

 Oooh, it's almost ready enough to let me replace my Thunderbird usage!

 A couple of feature requests (some I've already mentioned on IRC):

 * Support syntax highlighting for blocks enclosed with --- like DDoc
 does, maybe other types of blocks too such as {{{}}} that trac uses, or
 whatever github uses.
 * Does the mailing list have the same restriction as gmane has (no
 posting)?
 * Thundrbird has a "mark read" function for threads/messages/newsgroups
 - that'd be really useful.
 * In the horizontal-split view if you scroll down too far in the thread
 you can't see the current thread title, it would be good to make that
 sticky until you reach the next thread so you can see where you're up to

Another one - log in using OpenID so I don't have to remember another 
username/password ;)

-- 
Robert
http://octarineparrot.com/

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Such a sexy NG interface! The only thing missing is ability to quickly
switch between the main newsgroups in the horizontal-split view. I
mean if I'm reading D.learn there doesn't seem to be an obvious way to
switch to another group like D.announce. I can click on the title to
go back, of course, but it might be nice to have links to the other
NGs in that view (perhaps as a set of horizontal links above the
topics box).

Still, I love how fast it is. And it's written in D?! Sweet!

If this were integrated to dpl.org it would kick the balls out of all
the other proggy sites.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/8/2011 6:12 AM, Andrej Mitrovic wrote:
 Still, I love how fast it is. And it's written in D?! Sweet!

 If this were integrated to dpl.org it would kick the balls out of all
 the other proggy sites.

Yes! I also think this forum software will be highly desirable for others to 
use, and can be a showcase for what D programming can do.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham 
wrote:
 * Support syntax highlighting for blocks enclosed with --- like 
 DDoc does, maybe other types of blocks too such as {{{}}} that 
 trac uses, or whatever github uses.

I'm not very excited about the idea of introducing formatting 
features that only users of this web interface will see. Frequent 
use of such features would annoy users of other interfaces, and 
there's the risk of accidentally activating them.

 * Does the mailing list have the same restriction as gmane has 
 (no posting)?

Yes. Clicking on "Create thread" or "Reply" will display a 
message with a link to the Mailman page. I could probably 
implement posting if Brad says it's OK, but focused discussion 
groups such as development mailing lists might actually benefit 
from a high barrier to entry.

 * Thundrbird has a "mark read" function for 
 threads/messages/newsgroups - that'd be really useful.

"Mark thread as [un]read" keys should be easy to add. It would 
also be possible to mark all posts as read, but not on a 
per-group basis.

 * In the horizontal-split view if you scroll down too far in 
 the thread you can't see the current thread title, it would be 
 good to make that sticky until you reach the next thread so you 
 can see where you're up to

This isn't possible with just CSS. A JavaScript implementation 
might be possible. I'll think about it.

Maybe we should just reverse the thread sort order, like for the 
"threaded" view?

 Another one - log in using OpenID so I don't have to remember 
 another username/password ;)

I'd be happy to if you provide a D OpenID implementation :)

(Last I checked, implementing OpenID from scratch was quite hard)

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 15:06, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote:
 * In the horizontal-split view if you scroll down too far in the
 thread you can't see the current thread title, it would be good to
 make that sticky until you reach the next thread so you can see where
 you're up to

 This isn't possible with just CSS. A JavaScript implementation might be
 possible. I'll think about it.

It might be possible using the right combination of layers and absolute 
position.

-- 
/Jacob Carlborg

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 14:35:46 UTC, Jacob Carlborg 
wrote:
 On 2011-12-08 15:06, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham 
 wrote:
 * In the horizontal-split view if you scroll down too far in 
 the
 thread you can't see the current thread title, it would be 
 good to
 make that sticky until you reach the next thread so you can 
 see where
 you're up to

 This isn't possible with just CSS. A JavaScript implementation 
 might be
 possible. I'll think about it.

 It might be possible using the right combination of layers and 
 absolute position.

You still need to change from normal to fixed positioning when 
the title is scrolled offscreen, and vice-versa.

Here's one example (scroll down): http://lesscss.org/

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 15:39, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 14:35:46 UTC, Jacob Carlborg wrote:
 On 2011-12-08 15:06, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote:
 * In the horizontal-split view if you scroll down too far in the
 thread you can't see the current thread title, it would be good to
 make that sticky until you reach the next thread so you can see where
 you're up to

 This isn't possible with just CSS. A JavaScript implementation might be
 possible. I'll think about it.

 It might be possible using the right combination of layers and
 absolute position.

 You still need to change from normal to fixed positioning when the title
 is scrolled offscreen, and vice-versa.

 Here's one example (scroll down): http://lesscss.org/

Yeah, I guess so.

-- 
/Jacob Carlborg

Robert Clipsham <robert octarineparrot.com> writes:

On 08/12/2011 14:06, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote:
 * Support syntax highlighting for blocks enclosed with --- like DDoc
 does, maybe other types of blocks too such as {{{}}} that trac uses,
 or whatever github uses.

 I'm not very excited about the idea of introducing formatting features
 that only users of this web interface will see. Frequent use of such
 features would annoy users of other interfaces, and there's the risk of
 accidentally activating them.

I've seen quite a few people using it for code snippets anyway, and it's 
only a minor thing - I wouldn't want to go any further and allow for 
bold/italic/smileys/etc. Accidentally activating them would be a 
problem, I think that's a minor risk for this though. Not a major thing, 
just something I've always wanted to see ;)

 * Does the mailing list have the same restriction as gmane has (no
 posting)?

 Yes. Clicking on "Create thread" or "Reply" will display a message with
 a link to the Mailman page. I could probably implement posting if Brad
 says it's OK, but focused discussion groups such as development mailing
 lists might actually benefit from a high barrier to entry.

That's a shame, it really annoys me that I can't reply in the same place 
as I read currently :(

 * Thundrbird has a "mark read" function for
 threads/messages/newsgroups - that'd be really useful.

 "Mark thread as [un]read" keys should be easy to add. It would also be
 possible to mark all posts as read, but not on a per-group basis.

Awesome! Can't wait!

 * In the horizontal-split view if you scroll down too far in the
 thread you can't see the current thread title, it would be good to
 make that sticky until you reach the next thread so you can see where
 you're up to

 This isn't possible with just CSS. A JavaScript implementation might be
 possible. I'll think about it.

Some of us don't have the same reservations as Nick about not using 
javascript ;) If it can't be done in CSS it would still be really nice 
to have.

 Maybe we should just reverse the thread sort order, like for the
 "threaded" view?

<moreJavascript>
There could be a "Sort by" option to allow it to be sorted however the 
user wants it?
</moreJavascript>

 Another one - log in using OpenID so I don't have to remember another
 username/password ;)

 I'd be happy to if you provide a D OpenID implementation :)

 (Last I checked, implementing OpenID from scratch was quite hard)

I doubt I'll get chance in the near future unfortunately. Last time I 
looked it didn't seem to hard, I didn't look too in depth though.

-- 
Robert
http://octarineparrot.com/

Walter Bright <newshound2 digitalmars.com> writes:

On 12/8/2011 7:05 AM, Robert Clipsham wrote:
 I'm not very excited about the idea of introducing formatting features
 that only users of this web interface will see. Frequent use of such
 features would annoy users of other interfaces, and there's the risk of
 accidentally activating them.

 I've seen quite a few people using it for code snippets anyway, and it's only a
 minor thing - I wouldn't want to go any further and allow for
 bold/italic/smileys/etc. Accidentally activating them would be a problem, I
 think that's a minor risk for this though. Not a major thing, just something
 I've always wanted to see ;)

I agree to not do this.

maarten van damme <maartenvd1994 gmail.com> writes:

Beautiful newsgroup reader, makes a forum obselute but I am against making
features only available on the web interface. Maybe smileys and code tags
but no further then that.

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Thursday, 8 December 2011 at 14:06:48 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham 
 wrote:
 * Support syntax highlighting for blocks enclosed with --- 
 like DDoc does, maybe other types of blocks too such as {{{}}} 
 that trac uses, or whatever github uses.

 I'm not very excited about the idea of introducing formatting 
 features that only users of this web interface will see. 
 Frequent use of such features would annoy users of other 
 interfaces, and there's the risk of accidentally activating 
 them.

You do realize that > is a formatting feature, and like ---- it 
is visible to others. As a language news group having a way to 
segregate code would be useful even if only to be fixed. Reddit 
uses for leading spaces?

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Saturday, �� December 2011 at 00:10:26 UTC, Jesse Phillips 
wrote:
 You do realize that > is a formatting feature, and like ---- it 
 is visible to others. As a language news group having a way to 
 segregate code would be useful even if only to be fixed. Reddit 
 uses for leading spaces?

Using ">" for quotes is a widely-implemented standard (see e.g. 
RFC 3676) which applies directly to our situation.

"jdrewsen" <jdrewsen nospam.com> writes:

On Saturday, 10 December 2011 at 07:07:11 UTC, Vladimir Panteleev 
wrote:
 On Saturday, �� December 2011 at 00:10:26 UTC, Jesse 
 Phillips wrote:
 You do realize that > is a formatting feature, and like ---- 
 it is visible to others. As a language news group having a way 
 to segregate code would be useful even if only to be fixed. 
 Reddit uses for leading spaces?

 Using ">" for quotes is a widely-implemented standard (see e.g. 
 RFC 3676) which applies directly to our situation.

How do you feel about creating a setting that would make ---- 
regions formatted for code? Possibly default off.

Somebody might want this enough to send a patch.

/Jonas

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 11:55, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

Very nice. Although I would hope for a version that would work better in 
mobile phones. It's probably good to add a meta tag setting the scale 
for mobile phones.

This is a site that works good in basically all screen sizes:

http://upperdog.se/

-- 
/Jacob Carlborg

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg 
wrote:
 Very nice. Although I would hope for a version that would work 
 better in mobile phones. It's probably good to add a meta tag 
 setting the scale for mobile phones.

The "threaded" view mode should look the best on small screens.

 This is a site that works good in basically all screen sizes:

 http://upperdog.se/

Yes, I learned about the max-width CSS rules from that site when 
it was posted a while ago. However, CSS doesn't scale well for 
complex web pages.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/8/11 8:41 AM, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote:
 Very nice. Although I would hope for a version that would work better
 in mobile phones. It's probably good to add a meta tag setting the
 scale for mobile phones.

 The "threaded" view mode should look the best on small screens.

 This is a site that works good in basically all screen sizes:

 http://upperdog.se/

 Yes, I learned about the max-width CSS rules from that site when it was
 posted a while ago. However, CSS doesn't scale well for complex web pages.

How do they switch from column layout to no-column layout on tight widths?

Andrei

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 17:22:39 UTC, Andrei Alexandrescu 
wrote:
 On 12/8/11 8:41 AM, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg 
 wrote:
 This is a site that works good in basically all screen sizes:

 http://upperdog.se/

 Yes, I learned about the max-width CSS rules from that site 
 when it was
 posted a while ago. However, CSS doesn't scale well for 
 complex web pages.

 How do they switch from column layout to no-column layout on 
 tight widths?

There is a CSS rule which sets the divs (which are normally at 
31.25% width) to 100% width when the document is narrow enough.

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 15:41, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote:
 Very nice. Although I would hope for a version that would work better
 in mobile phones. It's probably good to add a meta tag setting the
 scale for mobile phones.

 The "threaded" view mode should look the best on small screens.

Yes, but try adding the following meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1 />

Then hopefully the page won't look zoomed out on mobile devices.

 This is a site that works good in basically all screen sizes:

 http://upperdog.se/

 Yes, I learned about the max-width CSS rules from that site when it was
 posted a while ago. However, CSS doesn't scale well for complex web pages.


-- 
/Jacob Carlborg

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg 
wrote:
 On 2011-12-08 15:41, Vladimir Panteleev wrote:
 The "threaded" view mode should look the best on small screens.

 Yes, but try adding the following meta tag:

 <meta name="viewport" content="width=device-width, 
 initial-scale=1 />

 Then hopefully the page won't look zoomed out on mobile devices.

OK, how does it look now?

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 18:49, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote:
 On 2011-12-08 15:41, Vladimir Panteleev wrote:
 The "threaded" view mode should look the best on small screens.

 Yes, but try adding the following meta tag:

 <meta name="viewport" content="width=device-width, initial-scale=1 />

 Then hopefully the page won't look zoomed out on mobile devices.

 OK, how does it look now?

Horribly broken, sorry, remove it. I was hoping the above would be a 
quick fix but I think a new CSS file would be needed. Don't spend time 
on creating a new CSS file for me, I'm fine using Thunderbird.

-- 
/Jacob Carlborg

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 19:58:11 UTC, Jacob Carlborg 
wrote:
 On 2011-12-08 18:49, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg 
 wrote:
 On 2011-12-08 15:41, Vladimir Panteleev wrote:
 The "threaded" view mode should look the best on small 
 screens.

 Yes, but try adding the following meta tag:

 <meta name="viewport" content="width=device-width, 
 initial-scale=1 />

 Then hopefully the page won't look zoomed out on mobile 
 devices.

 OK, how does it look now?

 Horribly broken, sorry, remove it. I was hoping the above would 
 be a quick fix but I think a new CSS file would be needed. 
 Don't spend time on creating a new CSS file for me, I'm fine 
 using Thunderbird.

OK. I don't have a smartphone, but if I get the chance I'll have 
a look at some possible simple fixes.

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 21:14, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 19:58:11 UTC, Jacob Carlborg wrote:
 On 2011-12-08 18:49, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote:
 On 2011-12-08 15:41, Vladimir Panteleev wrote:
 The "threaded" view mode should look the best on small screens.

 Yes, but try adding the following meta tag:

 <meta name="viewport" content="width=device-width, initial-scale=1 />

 Then hopefully the page won't look zoomed out on mobile devices.

 OK, how does it look now?

 Horribly broken, sorry, remove it. I was hoping the above would be a
 quick fix but I think a new CSS file would be needed. Don't spend time
 on creating a new CSS file for me, I'm fine using Thunderbird.

 OK. I don't have a smartphone, but if I get the chance I'll have a look
 at some possible simple fixes.

You can download a simulator, from the Android SDK or the iOS SDK. The 
iOS SDK requires a Mac. The simulator in Android SDK is extremely slow.

-- 
/Jacob Carlborg

Walter Bright <newshound2 digitalmars.com> writes:

On 12/8/2011 2:55 AM, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
DigitalMars
 NNTP server. I collected ideas and inspiration from the several threads on this
 topic in the last few weeks, and now I think that the result is ready for beta
 testing and general use.

I am very excited, this is freakin' awesome!

One question: where/how is the user registration data stored?

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 19:43:04 UTC, Walter Bright wrote:
 I am very excited, this is freakin' awesome!

I'm glad you like it :)

 One question: where/how is the user registration data stored?

In a table in an SQLite database. Passwords are stored as salted 
hashes right now.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/8/11 4:55 AM, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

This is an absolutely fantastic development. It's exactly the kind of 
thing that D needs - using D to write something nontrivial and highly 
useful. I just got in touch with Walter about it, and as of now you have 
in us strong supporters for replacing the existing Web bridge with this one.

One thing though - you must use hyphenation everywhere :o).

Here are a few large topics that we should discuss a bit:

- Would you consider merging your codebase with 
d-programming-language.org? That way we'd have a simple deployment 
target and simpler unified maintenance. The downside would be that your 
project would have less individuality as an independent NNTP-WWW bridge. 
(That could be partially addressed with directory structure etc.)

- If not, how do we go about integrating with 
d-programming-language.org? For example say we change the navigation 
panel on the left. Then we'd need to coordinate with you to pull the 
code, regenerate your own page, and so on.

- I'm thinking something with iframes may work for the above issue, but 
cross-domain iframes are limited. Could we serve your content off d-p-l.org?

My nits to be added to others':

* Registration flow is odd. You register, but then you're not taken back 
to the forums page.

* Password during registration appears in clear.

* The C and C++ forums should not be on the same page. We should focus 
only on the D forums. It's possible to link them via a new page.

* This may be a good time to retire a few unused forums such as dtl., 
debugger, dwt, ide, and merge their contents with digitalmars.D.

* The forum descriptions and possibly layout should emphasize 
digitalmars.D as the "main" forum, and digitalmars.D.learn as the "main 
n00b" forum. Generally first-comers will be confused as to where they 
should be posting when facing a large table that must be read in full, 
and most of the time they want either digitalmars.D or digitalmars.D.learn.

* The lists dmd-beta etc. should be under a different heading and 
deemphasized. They are for experts only and not nearly as prominent as 
the main forums.

* The style file should be loaded from d-p-l.org such that changes in 
style will be automatically picked up by the forums page.

* In horizontal split mode, the footer is disproportionately large (btw 
I made it smaller recently).

* Use of bold in split mode for unread posts seems a bit heavy. How 
about a different background color?

* It's not obvious how people should set up their own gravatar.


Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/8/11 2:15 PM, Andrei Alexandrescu wrote:
 On 12/8/11 4:55 AM, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

 This is an absolutely fantastic development.

One more thing:

- We should look at ways to integrate some of your code with the 
standard library. For example, would be great to put some NNTP and CGI 
support in std.


Andrei

Jacob Carlborg <doob me.com> writes:

On 2011-12-08 21:15, Andrei Alexandrescu wrote:
 On 12/8/11 4:55 AM, Vladimir Panteleev wrote:
 As mentioned previously, I've been working on a web frontend for the
 DigitalMars NNTP server. I collected ideas and inspiration from the
 several threads on this topic in the last few weeks, and now I think
 that the result is ready for beta testing and general use.

 The current (temporary) URL is:

 http://dfeed.kimsufi.thecybershadow.net/discussion/

 This is an absolutely fantastic development. It's exactly the kind of
 thing that D needs - using D to write something nontrivial and highly
 useful. I just got in touch with Walter about it, and as of now you have
 in us strong supporters for replacing the existing Web bridge with this
 one.

 One thing though - you must use hyphenation everywhere :o).

 Here are a few large topics that we should discuss a bit:

 - Would you consider merging your codebase with
 d-programming-language.org? That way we'd have a simple deployment
 target and simpler unified maintenance. The downside would be that your
 project would have less individuality as an independent NNTP-WWW bridge.
 (That could be partially addressed with directory structure etc.)

 - If not, how do we go about integrating with
 d-programming-language.org? For example say we change the navigation
 panel on the left. Then we'd need to coordinate with you to pull the
 code, regenerate your own page, and so on.

Perhaps as a git submodule in d-programming-language.org? Dfeed would 
change to only render the actual feed and somehow it gets included in 
the regular site. I'm not entirely sure how since the whole d-p-l.org 
site is rendered using ddoc.

-- 
/Jacob Carlborg

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 08 Dec 2011 15:15:37 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 - Would you consider merging your codebase with  
 d-programming-language.org? That way we'd have a simple deployment  
 target and simpler unified maintenance. The downside would be that your  
 project would have less individuality as an independent NNTP-WWW bridge.  
 (That could be partially addressed with directory structure etc.)

Hm... I don't understand the objection to having the project live on its  
own github repository.  It's not part of the documentation, but rather a  
separate piece of code that lives on the same server.  For example, I  
wouldn't expect the web newsreader to be downloaded in the zipfile.  Yes  
the navigation has to be updated, but I would concentrate more on making  
the navigation/header/footer independent of the forum code (if it isn't  
already).

-Steve

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 8 December 2011 at 20:15:38 UTC, Andrei Alexandrescu 
wrote:
 This is an absolutely fantastic development. It's exactly the 
 kind of thing that D needs - using D to write something 
 nontrivial and highly useful. I just got in touch with Walter 
 about it, and as of now you have in us strong supporters for 
 replacing the existing Web bridge with this one.

I'm excited :)

 One thing though - you must use hyphenation everywhere :o).

Now not so much :(

:)

 Here are a few large topics that we should discuss a bit:

 - Would you consider merging your codebase with 
 d-programming-language.org? That way we'd have a simple 
 deployment target and simpler unified maintenance.

I'm not against moving the project to the D-Programming-Language 
GitHub organization, but I'm not sure what would be achieved by 
merging the two git repositories. Git's "submodule" feature may 
be more helpful here.

One thing that needs to be mentioned is that the project's scope 
is not solely the web interface. "DFeed" actually started out as 
an IRC bot, which among other sources, included the newsgroup as 
an event source for IRC notifications. I've refactored the code 
to use a publish/subscribe pattern, so IRC and the local message 
database (used by the web interface) are two of the consumers. A 
third one will be the front-page news widget I was planning to 
have a go at.

 The downside would be that your project would have less 
 individuality as an independent NNTP-WWW bridge. (That could be 
 partially addressed with directory structure etc.)

This is actually not much of a problem right now, as the codebase 
wasn't written with much abstraction in mind, so refactoring it 
into a generic NNTP interface would be a task of its own (and 
probably better off as a fork of this project).

 - If not, how do we go about integrating with 
 d-programming-language.org? For example say we change the 
 navigation panel on the left. Then we'd need to coordinate with 
 you to pull the code, regenerate your own page, and so on.

This can be automated... Also, I'm not against the idea of 
providing direct shell access for D VIPs.

 - I'm thinking something with iframes may work for the above 
 issue, but cross-domain iframes are limited. Could we serve 
 your content off d-p-l.org?

Yes. By far the best method would be subdomains (e.g. 
forum.d-programming-language.org or discussion.d-p-l.org).

The second-best method is to use Apache's mod_proxy or 
mod_rewrite's [P] flag, to make a certain "directory" send web 
requests to my server. This would greatly affect latency, though 
- assuming d-p-l.org is hosted in the US, a request from an 
European visitor would need to make a roundtrip through the US 
and back to Europe, and back.

Frames are not much of an option, due to their 
non-interoperability with browser address bars.

 - We should look at ways to integrate some of your code with 
 the standard library. For example, would be great to put some 
 NNTP and CGI support in std.

I don't use CGI. The NNTP module implements little above what's 
needed for the task. There may be some code good enough for 
Phobos in the network library I use (asynchronous line-buffered 
sockets, HTTP client/server), but there are licensing issues I'd 
need to solve.

 My nits to be added to others':

 * Registration flow is odd. You register, but then you're not 
 taken back to the forums page.

It's a bug. I'll fix.

 * Password during registration appears in clear.

That was a deliberate choice... perhaps not a very good one.

 * The C and C++ forums should not be on the same page. We 
 should focus only on the D forums. It's possible to link them 
 via a new page.

Yes.

I was thinking about creating a digitalmars.com stylesheet, and 
sending the corresponding stylesheet and list of forums depending 
on the used URL / subdomain.

 * This may be a good time to retire a few unused forums such as 
 dtl., debugger, dwt, ide, and merge their contents with 
 digitalmars.D.

I'm not sure if merging groups is possible on the NNTP level. 
Doing it in DFeed would involve lots of hacks.

 * The forum descriptions and possibly layout should emphasize 
 digitalmars.D as the "main" forum, and digitalmars.D.learn as 
 the "main n00b" forum. Generally first-comers will be confused 
 as to where they should be posting when facing a large table 
 that must be read in full, and most of the time they want 
 either digitalmars.D or digitalmars.D.learn.

 * The lists dmd-beta etc. should be under a different heading 
 and deemphasized. They are for experts only and not nearly as 
 prominent as the main forums.

The layout is actually almost a verbatim copy of 
http://digitalmars.com/NewsGroup.html . The only change is a typo 
fix and addition of the omitted D-runtime list.

 * The style file should be loaded from d-p-l.org such that 
 changes in style will be automatically picked up by the forums 
 page.

I edited the main stylesheet to avoid yet another few !important 
CSS overrides. I think it's best to handle this in the same way 
as the HTML template (automatic or semi-automatic patching).

 * In horizontal split mode, the footer is disproportionately 
 large (btw I made it smaller recently).

Will fix.

 * Use of bold in split mode for unread posts seems a bit heavy. 
 How about a different background color?

I believe bolding is a common UI element used by newsreaders and 
mail clients. I just played with background colors a bit, and 
couldn't get it to not look weird.

However, how does it look now?

 * It's not obvious how people should set up their own gravatar.

Will fix.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/8/11 3:30 PM, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 20:15:38 UTC, Andrei Alexandrescu wrote:
 - Would you consider merging your codebase with
 d-programming-language.org? That way we'd have a simple deployment
 target and simpler unified maintenance.

 I'm not against moving the project to the D-Programming-Language GitHub
 organization, but I'm not sure what would be achieved by merging the two
 git repositories. Git's "submodule" feature may be more helpful here.

Essentially I'm looking at achieving a streamlined process that would 
allow me to type "make rsync" and deploy the whole thing. See 
https://github.com/D-Programming-Language/d-programming-language.org/bl
b/master/linux.mak. 
The process of generating an up-to-date site should be 100% automated.

 One thing that needs to be mentioned is that the project's scope is not
 solely the web interface. "DFeed" actually started out as an IRC bot,
 which among other sources, included the newsgroup as an event source for
 IRC notifications. I've refactored the code to use a publish/subscribe
 pattern, so IRC and the local message database (used by the web
 interface) are two of the consumers. A third one will be the front-page
 news widget I was planning to have a go at.

Sounds cool. Perhaps we'll get to modularize things nicely in the future.

 - I'm thinking something with iframes may work for the above issue,
 but cross-domain iframes are limited. Could we serve your content off
 d-p-l.org?

 Yes. By far the best method would be subdomains (e.g.
 forum.d-programming-language.org or discussion.d-p-l.org).

That should be doable but I should say I have a mild preference for 
directories because every subdomain operation would need a roundtrip to 
the website admin.

 * This may be a good time to retire a few unused forums such as dtl.,
 debugger, dwt, ide, and merge their contents with digitalmars.D.

 I'm not sure if merging groups is possible on the NNTP level. Doing it
 in DFeed would involve lots of hacks.

Oh, I was thinking of merging at file/archive level on the server, which 
would involve no work on your part. But let's not spread ourselves too thin.

 * The style file should be loaded from d-p-l.org such that changes in
 style will be automatically picked up by the forums page.

 I edited the main stylesheet to avoid yet another few !important CSS
 overrides. I think it's best to handle this in the same way as the HTML
 template (automatic or semi-automatic patching).

Anything that's 100% automated.

One thing I remembered from my list of nits - would be great to have 
votes like on reddit... but first I'd say let's go head to toe through 
one release of this software. I'll be looking forward to your 
integration ideas.


Andrei

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 09:17:11 UTC, Andrei Alexandrescu 
wrote:
 That should be doable but I should say I have a mild preference 
 for directories because every subdomain operation would need a 
 roundtrip to the website admin.

We need to decide on one URL structure and stick to it. Breaking 
links is bad.

A few people commented on the app's fast speed, so I'd hate to 
introduce an artificial bottleneck there.

Note that subdomains are tied to the DNS system, not web hosting. 
For example, I see that d-p-l.org was registered by Brad and is 
hosted on PureMagic's name servers, so he would be the person to 
contact regarding subdomains on d-p-l.org. 
d-programming-language.org is hosted on ns0/1.digitaldaemon.com 
and is registered to Walter.

You can make subdomains a CNAME (like an alias). That way, if I 
move servers, you won't need to bother whoever is responsible for 
the DNS records.

There are also some security considerations with attachments. We 
need to either have a separate subdomain for attachments, or 
forbid viewing them in the browser (which would mean that viewing 
non-whitelisted attachments, including HTML parts, would need to 
force a download). Gmail uses googleusercontent.com for 
attachments, for example.

 Essentially I'm looking at achieving a streamlined process that 
 would allow me to type "make rsync" and deploy the whole thing. 
 See 
 https://github.com/D-Programming-Language/d-programming-language.org/bl
b/master/linux.mak. 
 The process of generating an up-to-date site should be 100% 
 automated.

How about this: the makefile pings an URL on my server, which 
runs a script that downloads the files from 
http://d-programming-language.org/, patches and installs them?

A completely different approach would be to host the program on 
DigitalMars servers, but I'm worried that maintenance will become 
very difficult without access to it.

 Oh, I was thinking of merging at file/archive level on the 
 server, which would involve no work on your part. But let's not 
 spread ourselves too thin.

Yeah, that's what I meant. NNTP clients make assumptions 
regarding pre-existing server state which I don't see a way to 
maintain while merging group content.

 One thing I remembered from my list of nits - would be great to 
 have votes like on reddit... but first I'd say let's go head to 
 toe through one release of this software. I'll be looking 
 forward to your integration ideas.

This is a complicated issue - mainly due to the possibility of 
abuse. Reddit has complicated heuristic algorithms for detecting 
misbehavior and balancing votes, built up from years of 
experience. Even though their code is open, it's probably not 
worth the effort. We could make little attempt to police votes, 
but then they would lose meaning as soon as someone bored enough 
comes along.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/9/11 7:58 CST, Vladimir Panteleev wrote:
 On Friday, 9 December 2011 at 09:17:11 UTC, Andrei Alexandrescu wrote:
 That should be doable but I should say I have a mild preference for
 directories because every subdomain operation would need a roundtrip
 to the website admin.

 We need to decide on one URL structure and stick to it. Breaking links
 is bad.

Great.

 A few people commented on the app's fast speed, so I'd hate to introduce
 an artificial bottleneck there.

It's news to me that opting for subdomains vs. directories introduces 
significant differences in speed. Why?

 Note that subdomains are tied to the DNS system, not web hosting. For
 example, I see that d-p-l.org was registered by Brad and is hosted on
 PureMagic's name servers, so he would be the person to contact regarding
 subdomains on d-p-l.org. d-programming-language.org is hosted on
 ns0/1.digitaldaemon.com and is registered to Walter.

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.

 You can make subdomains a CNAME (like an alias). That way, if I move
 servers, you won't need to bother whoever is responsible for the DNS
 records.

 There are also some security considerations with attachments. We need to
 either have a separate subdomain for attachments, or forbid viewing them
 in the browser (which would mean that viewing non-whitelisted
 attachments, including HTML parts, would need to force a download).
 Gmail uses googleusercontent.com for attachments, for example.

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.

 Essentially I'm looking at achieving a streamlined process that would
 allow me to type "make rsync" and deploy the whole thing. See
 https://github.com/D-Programming-Language/d-programming-language.org/blob/master/linux.mak.
 The process of generating an up-to-date site should be 100% automated.

 How about this: the makefile pings an URL on my server, which runs a
 script that downloads the files from http://d-programming-language.org/,
 patches and installs them?

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? What would the 
URLs for posts look like?

 A completely different approach would be to host the program on
 DigitalMars servers, but I'm worried that maintenance will become very
 difficult without access to it.

I understand. We should find a way that allows you to play with the code 
and us to play with the other aspects of the website to keep it consistent.


Thanks,

Andrei

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Friday, 9 December 2011 at 15:15:05 UTC, Andrei Alexandrescu 
wrote:
 Interesting. I don't understand the security issues involved 
 and why they can't be addressed by the application, but you're 
 the doc.

Separate domains are a defense-in-depth kind of thing. The browser
puts up walls between domains for scripting, framing, cookies, 
locally
stored data, authentication headers, and so on.

While the app can filter this stuff, the separate domain helps be
sure that a bug in the app doesn't lead to a security hole in 
deployment.


And, of course, if you *want* to allow user scripting, the 
separate domain
is a must so put at least one hard wall in there.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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.

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

 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.

 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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 17:03:24 UTC, Vladimir Panteleev 
wrote:
 the program otherwise has no other dependencies

OK, that's a lie. It obviously needs SQLite, and it also uses 
iconv to decode messages in multibyte (non-UTF) encodings.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/9/11 11:03 AM, Vladimir Panteleev wrote:
 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.

I understand. So you want to approach this by serving forum content off 
your own server under the guise of d-programming-language.org. This 
should be fine.

 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.

Great. The remaining mid-term issue is as follows. Right now you own the 
database, which entails some fiduciary responsibilities. Think 
"unexpected": if e.g. you get hit by a bus (God forbid), the database is 
virtually lost. This scenario is solved by your granting e.g. Walter 
access to the server, so he can copy the database and possibly migrate 
the installation.

But then say you and Walter have a huge disagreement over a core issue, 
which makes you furious. Then you could revoke Walter's login and/or 
destroy the database. And so on.

Also, privacy is not a biggie right now because the database contains 
public information plus some simple preferences, but later you could 
store additional information of various degrees of sensitivity. So you 
would in fact responsible for users' privacy, but 
d-programming-language.org is the ostensible responsible.

How do you think we could solve this issue?


Andrei

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 19:01:27 UTC, Andrei Alexandrescu 
wrote:
 Great. The remaining mid-term issue is as follows. Right now 
 you own the database, which entails some fiduciary 
 responsibilities. Think "unexpected": if e.g. you get hit by a 
 bus (God forbid), the database is virtually lost. This scenario 
 is solved by your granting e.g. Walter access to the server, so 
 he can copy the database and possibly migrate the installation.

 But then say you and Walter have a huge disagreement over a 
 core issue, which makes you furious. Then you could revoke 
 Walter's login and/or destroy the database. And so on.

I must confess I have not considered for such a possibility. You 
are welcome to make periodic backups, of course.

 Also, privacy is not a biggie right now because the database 
 contains public information plus some simple preferences, but 
 later you could store additional information of various degrees 
 of sensitivity. So you would in fact responsible for users' 
 privacy, but d-programming-language.org is the ostensible 
 responsible.

Once the software is stable enough, we could move it together 
with the database to a DigitalMars server. Software solutions 
might also be possible (e.g. encrypting user data with their 
passwords).

Another possibility is to simply make it clear who is responsible 
for the data.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/9/2011 7:39 AM, Vladimir Panteleev wrote:
 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.

I hadn't thought about that.

I strongly suggest ignoring all sections of posting which are not plain text.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 19:48:46 UTC, Walter Bright wrote:
 I hadn't thought about that.

 I strongly suggest ignoring all sections of posting which are 
 not plain text.

What if someone with an NNTP client posts a question and attaches 
their D code?

If security is the sole problem with decoding attachments, it is 
easily mitigated with separate subdomains (or forced download). 
Whether it should be possible to post attachments is another 
question.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/9/2011 11:51 AM, Vladimir Panteleev wrote:
 On Friday, 9 December 2011 at 19:48:46 UTC, Walter Bright wrote:
 I hadn't thought about that.

 I strongly suggest ignoring all sections of posting which are not plain text.

 What if someone with an NNTP client posts a question and attaches their D code?

They can put it inline as text, the way it is done now.


 If security is the sole problem with decoding attachments, it is easily
 mitigated with separate subdomains (or forced download). Whether it should be
 possible to post attachments is another question.

It's not the sole problem, I mentioned a couple other in another post.

I reiterate that I strongly recommend ignoring attachments and html content. I 
think that trying to deal with them correctly and securely is a huge
distraction 
& time sink with little added value.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 19:54:28 UTC, Walter Bright wrote:
 They can put it inline as text, the way it is done now.

The problem is that they won't know that some users won't be able 
to view it. I don't suppose you can configure the NNTP server to 
reject attachments with a sensible error message?

 I reiterate that I strongly recommend ignoring attachments and 
 html content. I think that trying to deal with them correctly 
 and securely is a huge distraction & time sink with little 
 added value.

I think that's an exaggeration. The bulk of the work has already 
been done.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/9/2011 11:58 AM, Vladimir Panteleev wrote:
 On Friday, 9 December 2011 at 19:54:28 UTC, Walter Bright wrote:
 They can put it inline as text, the way it is done now.

 The problem is that they won't know that some users won't be able to view it. I
 don't suppose you can configure the NNTP server to reject attachments with a
 sensible error message?

I don't know if that can be done - but it is configured to reject posts that
are 
above a certain size. This tends to discourage attachments.

David Nadlinger <see klickverbot.at> writes:

On 12/9/11 4:15 PM, Andrei Alexandrescu wrote:
 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.

This strikes me as overly complicated. Why aren't the alias domains just 
301-forwarding all HTTP requests, including subdomains (wildcard), to 
the canonical one?

Also, the amount of time (resp. work) required for updating a domain 
record/zone file should really be far smaller than the time it takes for 
the changes to propagate to all the name servers out there. If not, 
there is something wrong (or the TTL way too low).

David

Walter Bright <newshound2 digitalmars.com> writes:

On 12/9/2011 5:58 AM, Vladimir Panteleev wrote:
 This is a complicated issue - mainly due to the possibility of abuse. Reddit
has
 complicated heuristic algorithms for detecting misbehavior and balancing votes,
 built up from years of experience. Even though their code is open, it's
probably
 not worth the effort. We could make little attempt to police votes, but then
 they would lose meaning as soon as someone bored enough comes along.

Much as I like the voting system, I agree that it may be not worth it due to 
dealing with abuse.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/9/2011 5:58 AM, Vladimir Panteleev wrote:
 There are also some security considerations with attachments. We need to either
 have a separate subdomain for attachments, or forbid viewing them in the
browser
 (which would mean that viewing non-whitelisted attachments, including HTML
 parts, would need to force a download). Gmail uses googleusercontent.com for
 attachments, for example.

I recommend ignoring attachments, including HTML ones. The current D archives 
ignores them, and it has never been an issue.

One reason is that with attachments people will tend to post their projects and 
bug reports to the n.g. rather than github (or equivalent) and bugzilla where 
they belong.

Another is to keep the posts readable by simple NNTP readers.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 9 December 2011 at 09:17:11 UTC, Andrei Alexandrescu 
wrote:
 On 12/8/11 3:30 PM, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 20:15:38 UTC, Andrei 
 Alexandrescu wrote:

 That should be doable but I should say I have a mild preference 
 for directories because every subdomain operation would need a 
 roundtrip to the website admin.

I just realized I missed another simple option: an entirely new 
domain, for example dpl-forum.net. I can take care of the 
registration and setup if you like the idea.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 12/9/11 9:06 AM, Vladimir Panteleev wrote:
 On Friday, 9 December 2011 at 09:17:11 UTC, Andrei Alexandrescu wrote:
 On 12/8/11 3:30 PM, Vladimir Panteleev wrote:
 On Thursday, 8 December 2011 at 20:15:38 UTC, Andrei Alexandrescu wrote:

 That should be doable but I should say I have a mild preference for
 directories because every subdomain operation would need a roundtrip
 to the website admin.

 I just realized I missed another simple option: an entirely new domain,
 for example dpl-forum.net. I can take care of the registration and setup
 if you like the idea.

At this point I'd say we have too many domains, not too few.

Andrei