Re: [issue2551027] wiki outgoing email does not work on sourceforge when running own wiki

Hi Bern:

In message <[email protected]>,
Bernhard Reiter writes:
>So we have to look for alternatives.
>Ideas:
>a) We activate SF's own wiki service
>  https://sourceforge.net/p/forge/documentation/Wiki/
>
>  For this we would have to transform the old contents into the
>  different format, they use Markdown.
>  Advantages: No extra credentials necessary, already integrated
>    with SF. HTTPS access.
>  We do not have to maintain the wiki software itself.
>
>b) We search for a different MoinMo.in provider
>  Advantage: We are the customers as we will be paying (a low amount),
>    transforming contents is easy, we profit from an independent
>    fully blown wiki component and also promote it. HTTPS and email included.
>
>c) We search for a hoster that offers us to run something.
>  Advantage: We have full control. And the advantages of a full blown
>    competitive wiki engine.

I have a few concerns:

 1) No loss/corruption of content. We have a lot of content that,
    because it includes python code, is brittle to
    transfer. Whitespace gets mangled easily and that causes semantic
    changes and bugs in python code. I have spent quite a few hours
    fixing pages in the wiki where whitespace rot has occurred.
 2) Anti-Spam controls. This was a problem in the past and is a
    concern for the future. Having a way to scrub spam if it occurs is
    going to be important. A way to control access (require magic key,
    or authorize users) to the wiki is a needed control if we wbend up
    in spam city.
 3) Vendor lock-in. The only thing I want to get locked into is
    roundup 8-).
 4) Support for HTTPS, RSS, and file/image attachments.
 4a) Being able to embed an attachment in the wiki page with syntax
    highlighting would be a nice to have. This would allow python code
    to be attached and the user can downloaded the file (preserving
    whitespace) rather than cut/paste.

It looks like the sourceforge wiki handles #4 but not #4a. I hope
because it ties into sourceforge, #2 is not an issue. #3 is an issue.
But if it reduces maintenance and we have some way to export the
content I am ok with it.

#1 is going to be the tricky issue. That argues for option b if
somebody is willing to pay for it.

--
				-- rouilj