www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A new web newsreader

reply "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
Dec 08 2011
next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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. :)
Dec 08 2011
prev sibling next sibling parent "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 !!
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent 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.
Dec 08 2011
prev sibling next sibling parent "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).
Dec 08 2011
prev sibling next sibling parent reply "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).
Dec 08 2011
parent 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.
Dec 08 2011
prev sibling next sibling parent 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
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent 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 :)
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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?
Dec 08 2011
prev sibling next sibling parent "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
Dec 08 2011
prev sibling next sibling parent "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 ;)
Dec 08 2011
prev sibling next sibling parent reply 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/
Dec 08 2011
next sibling parent reply 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/
Dec 08 2011
parent 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.
Dec 08 2011
prev sibling next sibling parent reply 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
Dec 08 2011
parent 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
Dec 08 2011
prev sibling parent reply 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/
Dec 08 2011
parent 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.
Dec 08 2011
prev sibling next sibling parent "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)
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent 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.
Dec 08 2011
prev sibling next sibling parent reply 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
Dec 08 2011
next sibling parent 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
Dec 08 2011
prev sibling parent reply 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
Dec 08 2011
parent reply 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
Dec 08 2011
parent 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
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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/
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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...
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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."
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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?
Dec 08 2011
prev sibling next sibling parent 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?
Dec 08 2011
prev sibling next sibling parent "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
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent reply 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
Dec 08 2011
next sibling parent 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
Dec 08 2011
prev sibling next sibling parent 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
Dec 08 2011
prev sibling parent reply 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
Dec 09 2011
next sibling parent reply 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
Dec 09 2011
next sibling parent reply 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
Dec 09 2011
parent 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
Dec 09 2011
prev sibling next sibling parent 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
Dec 09 2011
prev sibling parent reply 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.
Dec 09 2011
parent reply 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.
Dec 09 2011
parent 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.
Dec 09 2011
prev sibling next sibling parent 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:

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
Dec 09 2011
prev sibling next sibling parent 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.
Dec 09 2011
prev sibling parent 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.
Dec 09 2011
prev sibling next sibling parent "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
Dec 08 2011
prev sibling next sibling parent "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.
Dec 08 2011
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
--f46d04138ecd6d05c204b39b980b
Content-Type: text/plain; charset=ISO-8859-1

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.

--f46d04138ecd6d05c204b39b980b
Content-Type: text/html; charset=ISO-8859-1

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

--f46d04138ecd6d05c204b39b980b--
Dec 08 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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:

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.
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling next sibling parent "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?
Dec 09 2011
prev sibling next sibling parent "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.
Dec 09 2011
prev sibling parent "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
Dec 10 2011