Updated Running a public or community server (markdown)

Running-a-public-or-community-server.md

@@ -181,43 +181,61 @@ Impact to support requests - nil.
 This converts all links in your Friendica instance to the current http/https scheme. This is essential if you allow both http and https traffic, and have users who insist on using Internet Explorer.
 
 Server impact - low. 
+
 Impact to support requests - beneficial. IE users will no longer get mixed content warnings.
 
-*Dreamwidth Post Connector*
-This allows your users to cross post to dreamwidth blogs.
+-----
+
+*Dreamwidth Post Connector*
+
+This allows your users to cross post to Dreamwidth blogs.
+
+Server impact - low. Potentially high if you get a lot of users posting to Dreamwidth with lots of posts, but this rarely happens. 
 
-Server impact - low. Potentially high if you get a lot of users posting to dreamwidth with lots of posts, but this rarely happens. 
 Impact to support requests - low.
 
+-----
+
 *Editplain*
 
-Allows your users to use a plain text editor instead of the TinyMCE rich text editor. This is an essential plugin. Not only does TinyMCE break some things (code, iframe and embed tags) from time to time, but it's also annoying for experienced users. Everytime somebody turns it off, you also save system resources.
+Allows your users to use a plain text editor instead of the TinyMCE rich text editor. This is an essential plugin. Not only does TinyMCE break some things (code, iframe and embed tags) from time to time, but it's also annoying for experienced users. Every time somebody turns it off, you also save system resources.
 
-Server impact - negligible to negligibly beneficial, depending on it's popularity. 
-Impact to support requests - low...though somebody will turn it on and get confused at some point.
+Server impact - negligible to negligibly beneficial, depending on it's popularity among your users. 
+
+Impact to support requests - usually low... though somebody will turn it on without understanding it and get confused at some point.
+
+-----
 
 *External cron*
 
-This uses an external service to trigger a cronjob. A form of "poor man's cron". This is an inefficient alternative to a true cron. If you need an external cron, you shouldn't run a community site for more than half a dozen members.
+This uses an external service to trigger a cronjob. It's an inefficient alternative to a true cron. If you need an external cron, you shouldn't run a community site for more than half a dozen members.
 
-Server impact - site killer. 
-Impact to support requests - low.
+-----
 
 *Facebook connector*
 
-This allows near seamless integration of Friendica with your Facebook account. Cross post to Facebook, and receive posts and comments from friends and pages in real time. If you are a community server, you should think twice about allowing Facebook due to high resource use. You definitely shouldn't use synchronise comments, but you should use real time updates.  You should definitely use Facebook restrict to block the linking of Facebook friends.  If you do not restrict Facebook use, your site will die eventually.  Even if you think you're fine, you're probably not - the rapidly expanding item table will also hurt like hell.
+This allows near seamless integration of Friendica with your Facebook account. Cross post to Facebook, and receive posts and comments from friends and pages in real time. 
 
-On the other hand, if you're a community server, you can probably manage a few thousand Facebook contacts between your members.  If you have a small number of users - or lots of spare resources - you may be able to allow full Facebook.  A community server may find itself in a considerably better position than public servers when it comes to Facebook.  You are likely to be backed by your organisation, whereas most public servers are paid for by individuals.  This means you might be able to handle a more fully featured Facebook connector.  The safest bet is to restrict Facebook initially, and allow each of it's options one at a time, watching the resource demands closely until you find a level of integration you can sustain.
+If you are a _public_ server, you should think twice about allowing Facebook due to high resource use. If you decide to facilitate this plugin, you definitely shouldn't use the option "synchronise comments", but you should enable "Real-time updates" (which actually relieve the poller).  You should also use the _Facebook restrict_ plugin to block the linking of Facebook friends (see below).  If you do not restrict Facebook use, your site will most probably eventually pass out.  Even if you think you're fine, you may be in for nasty surprises - the rapidly expanding item table will cause problems over time.
 
-Server impact - rather high for a private server, very high indeed for a community server, debilitating for a public server. 
-Impact to support requests - high. The connector isn't 100% perfect (mostly, because Facebook's API isn't terribly good), but damn, will you know about it. You'll be asked to fix things that are often hard to fix, but normally impossible.
+On the other hand, if you're a _community_ server, you can probably manage a few thousand Facebook contacts between your members.  If you have a small number of users - or lots of spare resources - you may well be able to allow full Facebook connectivity.  A community server may find itself in a considerably better position than public servers when it comes to Facebook.  You are likely to be backed by your organisation, whereas most public servers are paid for by individuals.  This means you might be able to handle a more fully featured Facebook connector.  The safest bet for inexperienced community admins is to restrict Facebook initially, and allow each of its options one at a time, watching the resource demands closely until you find a level of integration you can sustain.
+
+Server impact - rather high (but manageable) for a private server, very high indeed for a community server, often debilitating for a public server. 
+
+Impact to support requests - fairly high. The connector isn't 100% perfect (mostly, because Facebook's API isn't terribly good). You'll be asked to fix things that are often hard to fix.
+
+-----
 
 *Facebook Restrict*
-Install this addon and new users will not be able to link friends with the Facebook connector. Existing users that are linking friends will not be affected.  New users will still be able to "throw things over the wall" (post to Facebook), and get comments on their posts. But they won't see posts/threads initiated by their Facebook contacts.
 
-Server impact - beneficial.  This plugin exists solely to release server load.  An essential plugin for all public/community websites using Facebook - at least initially while you judge it's resource demands.
+Install this addon and new users will not be able to link friends with the Facebook connector. Existing users that are linking friends will not be affected.  New users will still be able to "throw things over the wall" (post to Facebook friends), and get comments on their posts. But they won't see posts/threads initiated by their Facebook contacts.
+
+Server impact - beneficial.  This plugin exists solely to release server load.  An essential plugin for all public websites using the Facebook connector, and helpful to community admins, too - at least initially while you judge the connector's resource demands.
+
 Impact to support requests - high, if you do it after the fact.  Probably low if you do it from the outset.
 
+-----
+
 *Geonames*
 Use Geonames service to resolve nearest populated location for given latitude, longitude. Geonames takes latitude and longitude of where you're at (if you turn on "use browser location" in your settings) and tries to find the nearest population center.