Digital Mars - digitalmars.D

Brad Roberts <braddr puremagic.com> writes:

This has come up before and never really gone anywhere.  I've considered setting
up a new, modern, wiki for us to migrate to.  Prowiki has a number of
limitations that annoy me at least.  The biggest is it's history management
sucks.  Looking at what changed over time is either too hard for the likes of me
to figure out, or it's broken, or it just isn't available.

That said, I've only ever run one wiki package, mediawiki, and it was a pain in
the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
manage just off the official releases.

Anyone have a wiki package they've actually run (not just used via the web
interface) that they can recommend?  An obvious one is likely to be Trac via
dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).

Would any of you guys volunteer to help migrate content to it if one should
spring up?  I'd be willing to be one of those volunteers, but there's a lot of
content and it really shouldn't be moved over exactly as is.  A lot of
re-organization should be done.

My thoughts were to put it at d.puremagic.com to subsume the entire site, with
the exception of /issues which would continue to be the bugzilla installation.

Thoughts?

Later,
Brad

Jun 07 2009

Robert Clipsham <robert octarineparrot.com> writes:

Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.


Excellent idea! +1

 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.


I've also only run one wiki package too, mediawiki. From my experience 
it was good wiki software, but far too bloated. I'd also recommend 
installing whatever software you decide on from source rather than using 
the debian repositories, from my experience life is a lot easier as you 
actually know what's going on with the software :P

 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).


All I can do is give you 
http://en.wikipedia.org/wiki/Comparison_of_wiki_software to flick 
through, to see which packages do what you need, then have a play with 
some of them.

 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.


Volunteered.

 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.


Sounds good to me. If you need somewhere to mirror it I also don't mind 
volunteering for this.

 Thoughts?


While we're revamping the wiki, it might be a good idea to come up with 
a list of pages we want including in there. My ideas:

  * Tutorials
  * What compiler to use on what system/how to set it up ( 
http://docs.google.com/Doc?id=dghphd83_43ffpdbtcc could help with this)
  * Build tools (rebuild, dsss, xfbuild etc)
  * Editor/IDE support
  * Phobos vs Tango ( http://docs.google.com/Doc?id=dcswwfd8_48hq4fdwhd 
could help)
  * D1 vs D2
  * Links/resources (dsource, the spec etc)
  * FAQs
  * Language comparison (D vs *)
    * Benchmarks maybe?
  * Getting support (Newsgroups, IRC etc)

I could go on, that's probably enough to keep us going for a while though :P

 
 Later,
 Brad

Jun 08 2009

Brad Roberts <braddr bellevue.puremagic.com> writes:

On Mon, 8 Jun 2009, Robert Clipsham wrote:

 Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
 setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes
 of me
 to figure out, or it's broken, or it just isn't available.


 Excellent idea! +1


One thing I'm particularly interested in gathering is reasons NOT to start 
fresh on a new site.  A lot of +1's is interesting so far as to gather 
some sort of majority (as if the posters here are actually the majority), 
but real justifications either way are more valuable to me.

 That said, I've only ever run one wiki package, mediawiki, and it was a pain
 in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.


 I've also only run one wiki package too, mediawiki. From my experience it was
 good wiki software, but far too bloated. I'd also recommend installing
 whatever software you decide on from source rather than using the debian
 repositories, from my experience life is a lot easier as you actually know
 what's going on with the software :P


I have no trouble understanding how software works regardless of who 
packages it, be it the original distributor or a distribution's 
maintainer.  That's irrelevant.  What's relevant is which is easier to 
maintain in a real running situation over a broad span of time.

 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
 (sorry).


 All I can do is give you
 http://en.wikipedia.org/wiki/Comparison_of_wiki_software to flick through, to
 see which packages do what you need, then have a play with some of them.


Again, I really desire facts from experience, not a grid of feature 
comparisons.  I've done that reading, several times at various points over 
the years, it's useless for the questions that are really important to me.

 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot
 of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.


 Volunteered.


Excellent.

 My thoughts were to put it at d.puremagic.com to subsume the entire site,
 with
 the exception of /issues which would continue to be the bugzilla
 installation.


 Sounds good to me. If you need somewhere to mirror it I also don't mind
 volunteering for this.


Offsite backups are likely to be the only real requirement, and I've got 
that covered already.

Thanks,
Brad

Jun 08 2009

Jesse Phillips <jessekphillips gmail.com> writes:

On Sun, 07 Jun 2009 23:29:46 -0700, Brad Roberts wrote:

 This has come up before and never really gone anywhere.  I've considered
 setting up a new, modern, wiki for us to migrate to.  Prowiki has a
 number of limitations that annoy me at least.  The biggest is it's
 history management sucks.  Looking at what changed over time is either
 too hard for the likes of me to figure out, or it's broken, or it just
 isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a
 pain in the rear.  The debian packaging of it sucks.  I dunno if it's
 any easier to manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the
 web interface) that they can recommend?  An obvious one is likely to be
 Trac via dsource.  I've considered it, but personally I'm really not
 fond of trac (sorry).
 
 Would any of you guys volunteer to help migrate content to it if one
 should spring up?  I'd be willing to be one of those volunteers, but
 there's a lot of content and it really shouldn't be moved over exactly
 as is.  A lot of re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire
 site, with the exception of /issues which would continue to be the
 bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad


I was planning to do major reorganization of the prowiki content once I 
was done with classes. I personally hate wikis, but would be willing to 
contribute since there really isn't a good alternative. I also believe 
all obsolete content should be removed, there is little reason to 
preserve a versioned content.

Jun 08 2009

Yigal Chripun <yigal100 gmail.com> writes:

Walter Bright wrote:
 Jesse Phillips wrote:
 I also believe all obsolete content should be removed, there is little 
 reason to preserve a versioned content.


 The reason to keep a versioned content is when people argue about when 
 an idea first appeared and who gets the credit for it. It happens often 
 enough, and has saved my legal bacon on multiple occasions.
 
 Besides, storage is so cheap these days that can't be an issue. I was 
 stunned to find 1Tb drives for $89.99. I might even re-rip my CD 
 collection to FLAC <g>.


I think he meant to say that there is no need to have obsolete content 
in the *latest* version if the content is versioned and can be retrieved 
from the history.

I also hate wiki systems. I think even just plain old HTML with a git 
backend would be orders of magnitude better.
other alternatives that come to mind:

1) A CMS - depends on what package you choose but some are very good at 
organization of content and also no need to deal with different 
home-grown wiki dialects (I never understood what's the point of 
replacing HTML. NIH syndrome or something?)

2) google wave server would be extremely awesome once it's released 
later this year.

--yigal

Jun 08 2009

Brad Roberts <braddr bellevue.puremagic.com> writes:

On Mon, 8 Jun 2009, Yigal Chripun wrote:

 Walter Bright wrote:
 Jesse Phillips wrote:
 I also believe all obsolete content should be removed, there is little
 reason to preserve a versioned content.


 The reason to keep a versioned content is when people argue about when an
 idea first appeared and who gets the credit for it. It happens often enough,
 and has saved my legal bacon on multiple occasions.
 
 Besides, storage is so cheap these days that can't be an issue. I was
 stunned to find 1Tb drives for $89.99. I might even re-rip my CD collection
 to FLAC <g>.


 I think he meant to say that there is no need to have obsolete content in the
 *latest* version if the content is versioned and can be retrieved from the
 history.
 
 I also hate wiki systems. I think even just plain old HTML with a git backend
 would be orders of magnitude better.
 other alternatives that come to mind:
 
 1) A CMS - depends on what package you choose but some are very good at
 organization of content and also no need to deal with different home-grown
 wiki dialects (I never understood what's the point of replacing HTML. NIH
 syndrome or something?)
 
 2) google wave server would be extremely awesome once it's released later this
 year.
 
 --yigal


The killer feature of wiki's are that they're inline editable.  No need to 
work with multiple systems, just click, edit, view.  Yes, you can build 
that on top of almost any scm.  It's really not at all an interesting back 
end problem.  The challenge is ease of use.

Later,
Brad

Jun 08 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Yigal Chripun wrote:
 ...
 
 I also hate wiki systems. I think even just plain old HTML with a git
 backend would be orders of magnitude better.
 other alternatives that come to mind:


That's pretty much what a Wiki is, except that it has a web frontend to
edit the content.

Also, there are issues with using plain old HTML (see below).

 1) A CMS - depends on what package you choose but some are very good at
 organization of content


A wiki *is* a CMS.

 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)


<p>Because <tt>HTML</tt> can be <em>damned</em> verbose (and ugly, to
boot) at times.  Not to mention <strong>hard to read</strong>.</p>

Because ``HTML`` can be *damned* verbose (and ugly, to boot) at times.
Not to mention **hard to read**.

That said, there are some wiki formats that can FRO [1].  They're
generally still nicer to use than raw HTML once you know what the hell's
going on.  I personally prefer reStructuredText over pretty much
everything else.

 2) google wave server would be extremely awesome once it's released
 later this year.
 
 --yigal


I doubt that.  The demo was very good at being cool, but notice how it
*never* showed more than about five people in a conversation at once?
How exactly are you going to scale that up to an entire community?

Plus, having to manually add everyone to every conversation every time
you make a new page would be a tremendous pain in the ass.

It's a great replacement for personal email, not so much for ~(personal
email).

(I'm not saying having a Google Wave server of our own wouldn't be cool;
it just isn't appropriate for this task.)


[1] Uhh... "flip" right off.

Jun 08 2009

yigal chripun <yigal100 gmail.com> writes:

Daniel Keep Wrote:

 
 
 Yigal Chripun wrote:
 ...
 
 I also hate wiki systems. I think even just plain old HTML with a git
 backend would be orders of magnitude better.
 other alternatives that come to mind:


 That's pretty much what a Wiki is, except that it has a web frontend to
 edit the content.
 
 Also, there are issues with using plain old HTML (see below).
 
 1) A CMS - depends on what package you choose but some are very good at
 organization of content


 A wiki *is* a CMS.


no. I meant a CMS like joomla or something in that category.
 
 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)


 <p>Because <tt>HTML</tt> can be <em>damned</em> verbose (and ugly, to
 boot) at times.  Not to mention <strong>hard to read</strong>.</p>
 
 Because ``HTML`` can be *damned* verbose (and ugly, to boot) at times.
 Not to mention **hard to read**.
 
 That said, there are some wiki formats that can FRO [1].  They're
 generally still nicer to use than raw HTML once you know what the hell's
 going on.  I personally prefer reStructuredText over pretty much
 everything else.
 


huh? when you compose an HTML message in gmail do you write all those tags?? 
when you write a word document do you know what is the encoding of the content
is??

the format is an implementation detail that should *not* be exposed to the
user. a proper CMS provides you with UI to enter your content while a wiki has
NO proper UI. the only "advantage" a WIKI system has is that it uses a non
standard encoding format that each time you switch to a different WIKI you need
to convert all your content. 
the concept of a wiki is wrong by design. 

 2) google wave server would be extremely awesome once it's released
 later this year.
 
 --yigal


 I doubt that.  The demo was very good at being cool, but notice how it
 *never* showed more than about five people in a conversation at once?
 How exactly are you going to scale that up to an entire community?
 
 Plus, having to manually add everyone to every conversation every time
 you make a new page would be a tremendous pain in the ass.
 
 It's a great replacement for personal email, not so much for ~(personal
 email).
 
 (I'm not saying having a Google Wave server of our own wouldn't be cool;
 it just isn't appropriate for this task.)
 
 
 [1] Uhh... "flip" right off.


about google wave, I think you missed the point of the presentation completely.
the idea is that the system is extendable with plugins. you will not add people
to conversations manually but rather we will have a forum like system built _on
top_ of wave with plugins.

Jun 09 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

yigal chripun wrote:
 Daniel Keep Wrote:
 Yigal Chripun wrote:
 ...

 1) A CMS - depends on what package you choose but some are very good at
 organization of content




 no. I meant a CMS like joomla or something in that category.


What's the quantifiable difference?  The only one I can think of is that
CMSes are designed for closed-authorship sites (you have to register and
be approved) whereas Wikis are the other way around.  But since you can
change that, it doesn't seem like a reason to have a CMS, especially
since we *want* an open-authorship site.

 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)


 boot) at times.  Not to mention <strong>hard to read</strong>.</p>

 ...


 huh? when you compose an HTML message in gmail do you write all those tags?? 
 when you write a word document do you know what is the encoding of the content
is??
 
 the format is an implementation detail that should *not* be exposed to the
user. a proper CMS provides you with UI to enter your content while a wiki has
NO proper UI. the only "advantage" a WIKI system has is that it uses a non
standard encoding format that each time you switch to a different WIKI you need
to convert all your content. 
 the concept of a wiki is wrong by design. 


I hate in-browser rich text editors; every single one I've ever used
sucked massively.

For example, when I was posting on Blogger, I had to write every post
manually because their rich text editor was painful and crippled; it
wouldn't allow me to do the things I wanted to do.

Like use paragraphs.  Or insert internal links to footnotes.  You know,
really bloody basic stuff.

Until someone shows me a cross-browser rich text editor that doesn't
both blow and suck, I'm sticking to simplified markup; it's the only way
I get ANY control whatsoever.

 2) google wave server would be extremely awesome once it's released
 later this year.

 --yigal


 *never* showed more than about five people in a conversation at once?
 How exactly are you going to scale that up to an entire community?

 Plus, having to manually add everyone to every conversation every time
 you make a new page would be a tremendous pain in the ass.

 It's a great replacement for personal email, not so much for ~(personal
 email).

 (I'm not saying having a Google Wave server of our own wouldn't be cool;
 it just isn't appropriate for this task.)


 [1] Uhh... "flip" right off.


 about google wave, I think you missed the point of the presentation
completely. the idea is that the system is extendable with plugins. you will
not add people to conversations manually but rather we will have a forum like
system built _on top_ of wave with plugins. 


No, I saw that.  I *did* watch it.

My point is that Wave is exclusive communication, not inclusive.  You
start a wave by adding the people you're interested in, then they can
add to it.

A wiki, on the other hand, lets anyone edit it without explicit
permission.  Now, maybe you could write a plugin to publish waves to a
wiki or something... but at that point, why the hell aren't you just
using the wiki itself?

Jun 09 2009

yigal chripun <yigal100 gmail.com> writes:

Daniel Keep Wrote:

 
 
 yigal chripun wrote:
 Daniel Keep Wrote:
 Yigal Chripun wrote:
 ...

 1) A CMS - depends on what package you choose but some are very good at
 organization of content




 no. I meant a CMS like joomla or something in that category.


 What's the quantifiable difference?  The only one I can think of is that
 CMSes are designed for closed-authorship sites (you have to register and
 be approved) whereas Wikis are the other way around.  But since you can
 change that, it doesn't seem like a reason to have a CMS, especially
 since we *want* an open-authorship site.
 


the difference is in the UI (which a wiki doesn't provide) and the format used,
i.e. not some wiki format.

 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)


 boot) at times.  Not to mention <strong>hard to read</strong>.</p>

 ...


 huh? when you compose an HTML message in gmail do you write all those tags?? 
 when you write a word document do you know what is the encoding of the content
is??
 
 the format is an implementation detail that should *not* be exposed to the
user. a proper CMS provides you with UI to enter your content while a wiki has
NO proper UI. the only "advantage" a WIKI system has is that it uses a non
standard encoding format that each time you switch to a different WIKI you need
to convert all your content. 
 the concept of a wiki is wrong by design. 


 I hate in-browser rich text editors; every single one I've ever used
 sucked massively.
 
 For example, when I was posting on Blogger, I had to write every post
 manually because their rich text editor was painful and crippled; it
 wouldn't allow me to do the things I wanted to do.
 
 Like use paragraphs.  Or insert internal links to footnotes.  You know,
 really bloody basic stuff.
 
 Until someone shows me a cross-browser rich text editor that doesn't
 both blow and suck, I'm sticking to simplified markup; it's the only way
 I get ANY control whatsoever.


what you're complaining is a bug in *implementation* whereas what I complain
about is a bug in the *design*. the first I think is easier to fix.

I'm sure there must be somewhere on the web a descent implementation of a rich
text editor (google must have this somewhere). I'd even prefer a flash widget
that would provide proper UI instead of coding in some obscure wiki syntax. 
IMHO the gmail rich-text editor is descent enough. but if that's not good
enough it's always possible to create something better. 

 
 2) google wave server would be extremely awesome once it's released
 later this year.

 --yigal


 *never* showed more than about five people in a conversation at once?
 How exactly are you going to scale that up to an entire community?

 Plus, having to manually add everyone to every conversation every time
 you make a new page would be a tremendous pain in the ass.

 It's a great replacement for personal email, not so much for ~(personal
 email).

 (I'm not saying having a Google Wave server of our own wouldn't be cool;
 it just isn't appropriate for this task.)


 [1] Uhh... "flip" right off.


 about google wave, I think you missed the point of the presentation
completely. the idea is that the system is extendable with plugins. you will
not add people to conversations manually but rather we will have a forum like
system built _on top_ of wave with plugins. 


 No, I saw that.  I *did* watch it.
 
 My point is that Wave is exclusive communication, not inclusive.  You
 start a wave by adding the people you're interested in, then they can
 add to it.
 
 A wiki, on the other hand, lets anyone edit it without explicit
 permission.  Now, maybe you could write a plugin to publish waves to a
 wiki or something... but at that point, why the hell aren't you just
 using the wiki itself?


the current wiki requires to enter a name before you can edit any pages. the
reason specified for that is to prevent spam. 

with wave, the design would be something like a main wave that contains
sub-waves. The video shows how to organize multiple waves inside another wave
with a list of links to waves in the "main" wave.
so for editing the "wiki" you'd just need to add yourself to the main wave and
that will allow you to edit any of the sub-waves. 

I don't see any drastic differences between this and the above description of
the current wiki.

Jun 09 2009

BCS <none anon.com> writes:

Hello Yigal,

 Daniel Keep Wrote:
 
 yigal chripun wrote:
 
 Daniel Keep Wrote:
 
 Yigal Chripun wrote:
 
 ...
 
 1) A CMS - depends on what package you choose but some are very
 good at organization of content
 


 


 


 that CMSes are designed for closed-authorship sites (you have to
 register and be approved) whereas Wikis are the other way around.
 But since you can change that, it doesn't seem like a reason to have
 a CMS, especially since we *want* an open-authorship site.
 


 format used, i.e. not some wiki format.
 


One major *advantage* of wikies is that the UI is a browser. If I need to 
install anything (even a plugin, and lets pretend I don't have flash already) 
I'm not going to be contributing anything.

Jun 09 2009

Yigal Chripun <yigal100 gmail.com> writes:

BCS wrote:
 Hello Yigal,
 
 Daniel Keep Wrote:

 yigal chripun wrote:

 Daniel Keep Wrote:

 Yigal Chripun wrote:

 ...

 1) A CMS - depends on what package you choose but some are very
 good at organization of content






 that CMSes are designed for closed-authorship sites (you have to
 register and be approved) whereas Wikis are the other way around.
 But since you can change that, it doesn't seem like a reason to have
 a CMS, especially since we *want* an open-authorship site.


 format used, i.e. not some wiki format.


 One major *advantage* of wikies is that the UI is a browser. If I need 
 to install anything (even a plugin, and lets pretend I don't have flash 
 already) I'm not going to be contributing anything.
 


no. wikies are text based and have *NO* UI.
the flash widget was, as you said, "if all else fails" and we do not 
need to go to that extreme.

why is a standards based rich text editor so hard to envision? are we 
considering supporting all browsers since explorer 1.0 and that's why 
it's so hard?

IMO, this is doable. I am able to compose rich text messages in gmail 
without the need to learn some obscure wiki format. so maybe gmail 
doesn't provide support for all possible combinations of html tags but 
neither is the wiki format.

all i'm trying to say is that it's more productive IMO to try to fix the 
few problems that the current rich text editors have (according to other 
people's replies) than to give up and just use the wrong design.

Jun 09 2009

BCS <none anon.com> writes:

Hello Yigal,

 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.
 




No, I understand how wikies work, you use a web browser to edit text content 
that is then rendered as HTML. The UI is implemented via a web server and 
a web browser. Saying it has no UI is nonsensical as clearly the system
interfaces 
with a user so it /must/ have a UI of some kind.

 the flash widget was, as you said, "if all else fails" and we do not
 need to go to that extreme.


I hope your right there.

 why is a standards based rich text editor so hard to envision?


Envision? Easy. Implement? Hard. Heck, it's not that easy to do even under 
something like winforms.

 are we
 considering supporting all browsers since explorer 1.0 and that's why
 it's so hard?


I'm with you on that one.

 IMO, this is doable. I am able to compose rich text messages in gmail
 without the need to learn some obscure wiki format. so maybe gmail
 doesn't provide support for all possible combinations of html tags but
 neither is the wiki format.
 
 all i'm trying to say is that it's more productive IMO to try to fix
 the few problems that the current rich text editors have (according to
 other people's replies) than to give up and just use the wrong design.


In general, you may be correct, but for programmers, the cost of using non 
WYSIWYG is a lot smaller as we tend to be more practiced at reading around 
markup of different kinds and the cost of WYSIWYG (loss of flexibility) is 
much more noticeable because we tend to know and use more of the things that 
get lost.

Jun 09 2009

Yigal Chripun <yigal100 gmail.com> writes:

BCS wrote:
 Hello Yigal,
 
 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.




 No, I understand how wikies work, you use a web browser to edit text 
 content that is then rendered as HTML. The UI is implemented via a web 
 server and a web browser. Saying it has no UI is nonsensical as clearly 
 the system interfaces with a user so it /must/ have a UI of some kind.


I meant a graphical UI, as in a rich text editor. :)
obviously a wiki must have some kind of a UI, as you said.

 
 the flash widget was, as you said, "if all else fails" and we do not
 need to go to that extreme.


 I hope your right there.
 
 why is a standards based rich text editor so hard to envision?


 Envision? Easy. Implement? Hard. Heck, it's not that easy to do even 
 under something like winforms.


it's not impossible. and if there is one good enough open implementation 
it can be re-used.

 
 are we
 considering supporting all browsers since explorer 1.0 and that's why
 it's so hard?


 I'm with you on that one.
 
 IMO, this is doable. I am able to compose rich text messages in gmail
 without the need to learn some obscure wiki format. so maybe gmail
 doesn't provide support for all possible combinations of html tags but
 neither is the wiki format.

 all i'm trying to say is that it's more productive IMO to try to fix
 the few problems that the current rich text editors have (according to
 other people's replies) than to give up and just use the wrong design.


 In general, you may be correct, but for programmers, the cost of using 
 non WYSIWYG is a lot smaller as we tend to be more practiced at reading 
 around markup of different kinds and the cost of WYSIWYG (loss of 
 flexibility) is much more noticeable because we tend to know and use 
 more of the things that get lost.
 


we have a wiki at work (which I despise) and it always confuses me with 
it's weird syntax:
=text= vs. ==text==
i can never remember which one is the main title and which is the 
sub-title. I honestlly prefer html tags over this.

I also hate that you need to enter the text, than click preview, then 
fix the problems, then preview and so on. it feels like i'm debugging my 
content which is annoying and a waste of time compared to a work flow 
where you just see the end result in front of you in real time like in 
MS Word.

consider that this is why lyx (gui for latex) renders math in real-time. 
it's so much easier to write equations when you see what you entered 
instead of some obscure code to render it.

besides, I don't see why programmers must be punished by forcing them to 
use an inferior UI.

Jun 10 2009

Derek Parnell <derek psych.ward> writes:

On Wed, 10 Jun 2009 10:01:12 +0300, Yigal Chripun wrote:

 we have a wiki at work (which I despise) and it always confuses me with 
 it's weird syntax:
 =text= vs. ==text==
 i can never remember which one is the main title and which is the 
 sub-title. I honestlly prefer html tags over this.
 
 I also hate that you need to enter the text, than click preview, then 
 fix the problems, then preview and so on. it feels like i'm debugging my 
 content which is annoying and a waste of time compared to a work flow 
 where you just see the end result in front of you in real time like in 
 MS Word.
 
 consider that this is why lyx (gui for latex) renders math in real-time. 
 it's so much easier to write equations when you see what you entered 
 instead of some obscure code to render it.
 
 besides, I don't see why programmers must be punished by forcing them to 
 use an inferior UI.


A wiki engine is a text to HTML translator. I've written one, based on the
Creole markup syntax, so I sort know what's involved. 

There are situations in which writing raw HTML is not the better option,
such as embedded documentation within source code. Ddoc is a kind-of wiki
engine in this regard. There is nothing intrinsically wrong with using a
simplified markup syntax via text UI, because it can be better, or the
only, solution in some common cases.

In order to write a wiki page I do not need any sophisticated software to
help me ... I can just do it with the simplest of text editors.

By the way, if one can't remember that '=' is a 1st level heading, and "=="
is a 2nd level heading and "===" is a 3rd level heading, etc ... then I'm
don't know how one can remember all the equivalent HTML tags.

I really would not like depending solely on a GUI application to write
source code that has embedded documentation.

There is a valid place for both models of creating a HTML page.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Jun 10 2009

Yigal Chripun <yigal100 gmail.com> writes:

Derek Parnell wrote:

 A wiki engine is a text to HTML translator. I've written one, based on the
 Creole markup syntax, so I sort know what's involved. 
 
 There are situations in which writing raw HTML is not the better option,
 such as embedded documentation within source code. Ddoc is a kind-of wiki
 engine in this regard. There is nothing intrinsically wrong with using a
 simplified markup syntax via text UI, because it can be better, or the
 only, solution in some common cases.
 
 In order to write a wiki page I do not need any sophisticated software to
 help me ... I can just do it with the simplest of text editors.
 
 By the way, if one can't remember that '=' is a 1st level heading, and "=="
 is a 2nd level heading and "===" is a 3rd level heading, etc ... then I'm
 don't know how one can remember all the equivalent HTML tags.


it's simple, HTML clearly denotes what's the markup and what's the 
content and provides clear structure for the document. Wiki formats are 
fuzzy to me. there's no clear distinction between markup and content.

 
 I really would not like depending solely on a GUI application to write
 source code that has embedded documentation.


that's a completely different use case. we were discussing writing 
content for the web, not writing D programs.
 
 There is a valid place for both models of creating a HTML page.
 


of course I'd want to be able to paste D snippets and have the system 
highlight it and parse the inline documentation. however, when people 
write non-code content they shouldn't be forced to write it in DDOC, 
should they?

Jun 10 2009

BCS <none anon.com> writes:

Hello Yigal,

 BCS wrote:
 
 Hello Yigal,
 
 BCS wrote:
 
 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.
 


 


 content that is then rendered as HTML. The UI is implemented via a
 web server and a web browser. Saying it has no UI is nonsensical as
 clearly the system interfaces with a user so it /must/ have a UI of
 some kind.
 




Yup, that sounds reasonable. OTOH I wouldn't use a non-web based GUI for 
a wiki.

 as in a rich text editor. :)


have you seen the editor used by stackoverflow.com? It has realtime preview 
and even code highlighting.

Jun 10 2009

Yigal Chripun <yigal100 gmail.com> writes:

BCS wrote:
 Hello Yigal,
 
 BCS wrote:

 Hello Yigal,

 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.




 content that is then rendered as HTML. The UI is implemented via a
 web server and a web browser. Saying it has no UI is nonsensical as
 clearly the system interfaces with a user so it /must/ have a UI of
 some kind.




 Yup, that sounds reasonable. OTOH I wouldn't use a non-web based GUI for 
 a wiki.
 
 as in a rich text editor. :)


 have you seen the editor used by stackoverflow.com? It has realtime 
 preview and even code highlighting.
 
 


not like a batch C++ compiler but more like a python interpreter.

Jun 10 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Brad Roberts wrote:
 On Tue, 9 Jun 2009, Yigal Chripun wrote:
 
 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.


 are listed as having a stable WYSIWYG editor (some of the others are listed
 as having an alpha or beta one)...

         Jerome

 (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software


 the standard HTML format as the backend?


 In an attempt to help this thread end... 
 
 Thanks, the bicycle shed is a nice pretty new color and doesn't need any 
 more paint.
 
 Sigh,
 Brad
 
 (Why is it that people can't stick to the original question and avoid the 
 100% pointless side discussion?  No, really, don't answer that)


Consider yourself lucky. At least in this case people don't come with 
their *own* wiki format. Compare and contrast with the endless recent 
discussion on how switch should look like...


Andrei

Jun 09 2009

Yigal Chripun <yigal100 gmail.com> writes:

Brad Roberts wrote:
 On Tue, 9 Jun 2009, Yigal Chripun wrote:
 
 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.


 are listed as having a stable WYSIWYG editor (some of the others are listed
 as having an alpha or beta one)...

         Jerome

 (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software


 the standard HTML format as the backend?


 In an attempt to help this thread end... 
 
 Thanks, the bicycle shed is a nice pretty new color and doesn't need any 
 more paint.
 
 Sigh,
 Brad
 
 (Why is it that people can't stick to the original question and avoid the 
 100% pointless side discussion?  No, really, don't answer that)
 


this is not a pointless side discussion, you asked for alternatives for 
the current wiki and we were discussing such alternatives.

There is no bicycle shed issue here - on the contrary, I'm arguing 
*against* trying to choose between different wiki formats and instead go 
for the web's standard format, [X]HTML.

if that would have been done in the first place you wouldn't need 
volunteers to help you convert the content to the new wiki that you are 
going to choose.

Jun 09 2009

Brad Roberts <braddr bellevue.puremagic.com> writes:

On Tue, 9 Jun 2009, Yigal Chripun wrote:

 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.
 


 are listed as having a stable WYSIWYG editor (some of the others are listed
 as having an alpha or beta one)...
 
         Jerome
 
 (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software


 if these wikies provide a wysiwyg editor than what's the point of not using
 the standard HTML format as the backend?


In an attempt to help this thread end... 

Thanks, the bicycle shed is a nice pretty new color and doesn't need any 
more paint.

Sigh,
Brad

(Why is it that people can't stick to the original question and avoid the 
100% pointless side discussion?  No, really, don't answer that)

Jun 09 2009

Robert Fraser <fraserofthenight gmail.com> writes:

Jarrett Billingsley wrote:
 On Tue, Jun 9, 2009 at 10:40 AM, Daniel Keep<daniel.keep.lists gmail.com>
wrote:
 I hate in-browser rich text editors; every single one I've ever used
 sucked massively.

 For example, when I was posting on Blogger, I had to write every post
 manually because their rich text editor was painful and crippled; it
 wouldn't allow me to do the things I wanted to do.

 Like use paragraphs.  Or insert internal links to footnotes.  You know,
 really bloody basic stuff.

 Until someone shows me a cross-browser rich text editor that doesn't
 both blow and suck, I'm sticking to simplified markup; it's the only way
 I get ANY control whatsoever.


 QFT


Okay, but let's choose a wiki that has an _optional_ rich text editor 
for those of us who aren't technophobic.

Jun 09 2009

eris <jvburnes gmail.com> writes:

Brad Roberts Wrote:

 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.


Brad,

I've used MediaWiki, ZWiki and MoinMoin.  Despite its silly name, I think I
liked MoinMoin the best.  It has an ample user base, is written in Python, has
reasonable performance, has plugins, doesn't need a database backend and is
simple to admin.

eris

 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

Jun 08 2009

eris <jvburnes gmail.com> writes:

Brad Roberts Wrote:

 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.


Brad,

I've used MediaWiki, ZWiki and MoinMoin.  Despite its silly name, I think I
liked MoinMoin the best.  It has an ample user base, is written in Python, has
reasonable performance, has plugins, doesn't need a database backend and is
simple to admin.

eris

 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

Jun 08 2009

eris <jvburnes gmail.com> writes:

eris Wrote:

 Brad Roberts Wrote:
 
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.


 Brad,
 
 I've used MediaWiki, ZWiki and MoinMoin.  Despite its silly name, I think I
liked MoinMoin the best.  It has an ample user base, is written in Python, has
reasonable performance, has plugins, doesn't need a database backend and is
simple to admin.
 



MoinMoin also has extensive page revision history support.  It will allow you
to view/rollback to the previous 100 versions.  You can go back further than
that, but it thats what the view provides.

eris

Jun 08 2009

Nick B <nick.barbalich gmail.com> writes:

Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad


Brad

You might want to check out silverstripe.  Its very good.

Go here for the home page:

http://www.silverstripe.com/

100,000 users

Go here for the community showcase :

http://www.silverstripe.org/community-showcase?start=0

cheers
Nick B

Jun 10 2009

Helmut Leitner <leitner wikiservice.at> writes:

Dear Brad (and others),

as you know (or maybe not) I've installed the wiki4d as a part of my enthusiasm
for D. There was an older wiki that didn't really work, was unsupported and
slow.

The *real* work was done by Justin Calvarese and all the others contributing.

I did not invest in special adaptations that are typical for such projects
but I supported and kept the it running since March 2003. Last year I moved
it to a new server and the performance is good again.

My personal D-relationship went through ups and lows, but whatever the current
state is, I'll support this wiki as long as it is wanted or needed.

I'm not pissed off, if the community decides to switch. But you should think
about what you really need and not jump on something superficial.

Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.


Sorry, this sounds fuzzy to me. What problem do you actually have?

There is a complete RCS-history of each page from day 1, e.g. 140
FrontPage-versions.
You have to store your user name with your "Preferences" to access this
"Archive",
because ProWiki prefers not to expose it to search engine robots.

If you are unable to access it, we can probably add/improve some help text.

 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.


There are many people who like mediawiki, some dilike it, but all agree that
it is easy to get up and running, let's say in 5-30 minutes. You only would
need to worry if you want to run the server. Honestly, from what you are
writing, I do not think that you are up to this task.

The problems always start, when one wants it not to act or look like a flat
mediawiki encyclopedia. Or do something beyond the standard features.

Basically it should be sufficient for what the D-community needs.

 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?


I think the main point is not to decide on some shiny new wiki package but
to have someone who guarantees the server, it's performance and support,
for the next few years, whatever system it is runnning.

Wiki4D has been an easy burden because the people using it have been very
nice and intelligent, needing a minimum of external support. Nevertheless
I wouldn't mind stopping it, because of the resources it needs.

Walter just needs to tell me when to switch the OFF-button.

Kind regards,
Helmut

P.S. Please send me an e-mail in case of something I should react to, because
      I check this news feed only every other month.

 Later,
 Brad

Jun 16 2009

=?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:

Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad


At my company, we have been using Redmine for a year now. Redmine is 
comparable to Trac, but with a lot less effort to maintain, since almost 
everything is configurable through the web interface *out of the box*. 
It’s basically a project management application, but the wiki is a 
crutial part of it, using textile as markup language.

And before anyone comes up with another bikeshed-argument: textile is in 
use by all employees of this company, *especially* non-IT people. We 
also use it in our home-grown blog software, and not even users 
submitting blog posts ever had a problem with using it. Most people even 
really like it because it’s so simple and intuitive! :)

I would help setting up a Redmine installation and content migration, 
too, of course. It’s using Ruby on Rails, btw., and can be either 
deployed with a mongrel cluster or via mod_passenger (though I don’t 
have any experience with the latter).

ad Helmut:
I think Brad knows quite well how to keep a server running and maintain 
a community website. :)

Jun 17 2009

digitalmars.D - D Wiki