NextCMS

Bislang habe ich die MSXFAQ komplett mit dem Programm "Sharepoint Designer 2007" verwaltet. Die Hintergründe sind auf Backstage schon beschrieben. Dennoch muss ich mir natürlich Gedanken über die Zukunft der MSXFAQ machen bzw. eher wie ich den Content zukünftig verwalten und editieren möchte. Diese Seite beschreibt die Gründe und Überlegungen.

Aus der Planung 2018 wurde schon 2019 und vermutlich auch noch 2020. Aktuell tendiere ich dazu, die MSXFAQ mit GIT und Markdown zu verwalten und zu konvertieren.

Warum etwas ändern?

Sharepoint Designer 2007 erfüllt fast alle meiner Anforderungen an die Verwaltung einer Webseite, z.B. Offline Bearbeiten, mit Vorlagen das Layout gestalten und mit VBA umfangreiche Veränderungen der Seiten automatisiert durchführen. Das kann auch unterwegs erfolgen und danach lade ich einfach statische HTML-Seiten auf die Webseite hoch. Aber es gibt einige Dinge, die besser sein können:

  • End of Life.
    Schon Sharepoint Designer 2010 konnte nicht mehr mit "DiskWebs" arbeiten und ich musste bei Sharepoint Designer 2007 bleiben. SPD2013 ist nicht mal mehr ein richtiger "Webseiteneditor" sondern viel mehr ein Sharepoint Programmier-GUI. Womit werde ich zukünftig meine Seiten bearbeiten, wenn Sharepoint Designer 2007 nicht weiter unterstützt wird und sich bald vielleicht nicht mehr installieren lässt?
  • Suspekte Bugs
    Immer wieder habe ich den Eindruck, dass Fehler im SharePoint Designer mir das Leben schwer machen. Manchmal werden Umlaute einfach durch ein "�" oder andere Sonderzeichen ersetzt:

    Auch scheint die "Navigation" manchmal Seiten zu verlieren oder falsch zu verknüpfen. Ich bin sicher, dass Microsoft diese Fehler vermutlich schon kennt aber nicht mehr fixen wird. Ich habe einige passende Treffer, die auf den Zeichensatz hinweisen, aber suspekt bleibt das schon. Ich habe der Thematik eine eigene Seite auf Stress mit umlauten gewidmet.
  • Fehlende MultiUser Bearbeitung
    Manchmal wünsche ich mir schon, dass z.B. mehrere Personen die Seiten überarbeiten und z.B. Tippfehler korrigieren aber vielleicht auch Content beisteuern. Mit Sharepoint Designer geht das zwar aber nicht wenn die Bearbeiter "Disconnected" sind. Interessanter wäre hier schon, wenn jede Seite als Quelle "autark" wäre und man nur diese Änderungen abgleichen müsste. Das kommt dann aber dem Schritt entgegen, dass man an einer Stelle die Seiten erstellen und pflegt aber diese zur "Veröffentlichung" erst generiert werden. So ein Ablageort müsste dann natürlich eine Versionierung oder Ein/Auschecken unterstützen.
  • Struktur und Themen
    Aktuell gibt es an der linken Seite ein Menü, welches jede Seite genau einmal enthält und damit quasi das "Inhaltsverzeichnis" ist. Es gibt aber immer wieder Seiten, die nicht genau einzuordnen sind. Zudem ist die Dateistruktur auf dem Webserver (und meinem Notebook) nicht genau mit der Navigation übereinstimmend. Das macht alles nicht einfacher und manchmal zerhaut Sharepoint Designer sogar die Navigationsstruktur. Ich würde daher lieber die Dateien in einer "Dateistruktur" ablegen aber in der Navigation freier z.B. nach Themen die Seiten zusammen anzeigen.
  • Layout und mobile Seite
    Generell ist das Layout der letzten Jahre natürlich für "Desktops" optimiert gewesen. Aber Tablets, Smartphones etc. nehmen zu und auf Dauer müsste das Design schon etwas besser auf kleine Displays angepasst werden. Vom Text her ist das auch kaum ein Problem aber die Navigation ist hier mein großes Sorgenkind. Es sind einfach zu viele Menüs um mit großflächigen Kacheln oder Texten zu arbeiten. Die Menüs müssen straffer werden.
  • Der richtige Editor
    Sharepoint Designer 2007 ist ein ziemlich guter HTML-Editor, der nicht viel Mist macht und über CSS-Styles und DWT-Vorlagen den Bearbeiter streng in einem Korridor führt. Aber wie sieht hier die Zukunft aus ?. Vielleicht wird es doch mal "WordApp" oder "WinWord"?. Wie wissen alle, dass die HTML-Exportfunktion von Office schrecklich ist. Aber vielleicht kann ich Wort per DOTX-Vorlage mit erzwungenen Vorlagen dazu bringen, DOCX zu schreiben, welches dann (es ist ja eine ZIP-Datei mit XML und Images) durch einen Automatismus geparst werden kann.
    Aktuell bin ich mit dem "Rich Editor" a la SharePoint Designer eben verdammt schnell bei der Überarbeitung von Seiten. Das wird in einem Browser mit Wordpress und Co nicht so effektiv gehen.
  • Hyperlinks und Verweise
    Ich versucht möglichst viele Seiten miteinander zu verbinden. Aber das Problem sind natürlich neue Seiten, die zwar auf viele andere Seiten verweisen aber selbst von anderen Seiten noch nicht referenziert werden. Hier finde ich ein WIKI schon genial, wo in Seiten verweise auf nicht existente Seiten gesetzt werden können. Vielleicht gelingt es mir aber auch über die Keywords einer Seite solche Linkseiten zu erstellen oder direkte Links zu generieren.
  • Text-Normierung
    Es gibt sehr viele "Tippfehler" die immer wieder passieren, z.B. Exchange statt Exchange oder unterschiedliche Schreibeweisen von On-Prem (z.B. On-Prem, On-Prem etc.). Die schlimmsten Fehler könnte so ein Skript fixen oder den Autor auf zu viele Fehler hinweisen, damit die Dokumente leserlich bleiben.

Überlegungen

Ich habe mich immer wieder mit Content Systemen wie Joomla, WordPress und anderen beschäftigt aber zum einen stört mich, dass diese immer nur "online" bearbeitet werden können und ein Browser nun mal noch keine "Rich Application" wie den Sharepoint Designer ersetzen kann. Sicher könnte ich z.B. mit dem "LiveWriter" arbeiten aber auch hier ist die Zukunft ja nie gesichert. Wobei.. wo ist das schon.

Nein, ich habe mir gedacht, dass die ganze Welt mit Textverarbeitungsprogrammen arbeitet und ich das ja auch so mache. Was sollte mich daran hindern, die Inhalte einfach als DOCX-Dateien an einem geeigneten Ablageort (GitHub, SharePoint, o.ä.) abzulegen. Der Baum könnte die logische Struktur, quasi das Inhaltsverzeichnis darstellen, wobei die Sortierung noch zu klären wäre, z.B. durch manuell gepflegte "INDEX"-Seiten. Allerdings kann ein Webserver zwar ein DOCX ausliefern aber Anzeigen ist etwas andere. Da sollte es schon HTML sein. Da ich aber keine "werbe-dynamische" Webseite betreibe und die Last auf dem Webserver minimal halten möchte, sollte ein Prozess einfach anhand der Dateien die Zieldateien generieren. So kommen dann ein paar Stichpunkte zusammen:

  • Word oder andere Textverarbeitung erstellt Dateien in einem Verzeichnisbaum
    Die Software stellt sicher, dass nur "vordefinierte Styles" verwendet werden können. Interessant wird es natürlich, wenn diese Ausgangsseiten vielleicht automatisch von anderen Daten generiert werden und so ein Dokumentationssystem für eine Firma entstehen kann.
  • Einstiegsseite, Bereiche und "Themenseiten"
    Ich denke an eine Homepage, die auf verschiedene "Bereiche" verweist, unter denen dann "Themenseiten" die verschiedenen Informationen zusammenführen.
    Die ganze Struktur sollte also maximal 2 Ebenen haben. Ich weiß, dass dies mit >3000 Seiten schon sportlich wird. z.B. 10 "Bereiche" mit 50 Themenseiten ergeben im Optimalfall 500 Seiten, die auf die 2600+ Inhaltsseiten verweisen. lassen immer noch 5 Seiten pro Themenseite übrig. Und es werden sicher mehr werden. Aber damit wird ein "Mobiles Menü" natürlich sehr elegant möglich.
    Der "Tree" dient nur noch zur Sitemap und Erstellen von Index-Seiten und der Navigationsleiste am oberen Rand.
  • Keywords und Themenseiten
    Vielleicht gelingt es mir ja, die Themenseiten anhand der Keywords auf jeder Seite zu erstellen oder zumindest zu füllen. Im Idealfall wird eine "Keyword-Seite" erstellt, auf der alle Seiten mit diesem Keyword verlinkt werden. Im zweiten Schritt könnte man nach den Keywords im Fließtext suchen und so auf die Keyword-Seite verlinken. Dann müsste man als Autor quasi an gar nichts mehr denken. Denkbar wäre auch die Überschriften als Keyword heran zu ziehen. Ich denke da an die Zukunft als "Dokumentationssystem", wenn jemand eine Liste der IP- Netze in einer Tabelle hat und es zu jedem Subnetz eine vielleicht automatisch generierte Seite gibt. Wobei diese Generierung natürlich auch gleich das "Keyword" entsprechend füllen könnte.
  • Fehlersuchseiten
    Um Fehler zu erkennen, sollte die Generierung z.B. "unverknüpfte" Seiten, ungültige Styles, Seiten ohne Keyword etc. finden, die also nirgendwo enthalten sind. Die Berichte von Sharepoint Designer 2007 gaben hier schon erste Hilfestellungen.
  • Generierung
    Da ich meine Webseite "Lokal" erstelle und dann nach einem Generierungslauf erst per FTP" hochladen", kann ich davon nur gutes berichten. Daher ist auch das mein erster Ansatz. Aber vielleicht könnte man diese Generierung sogar auf einen Server delegieren, der ein Einchecken einer Seite die Updates durchführt.
  • Anzeige im Browser - Bearbeitung in Word
    Das primäre und auch einzige "Client" ist ein HTML-Browser, egal auf welchem Gerät. Aber wenn ich eine Seite editieren will, könnte ja ein Link auf die WordDatei (UNC, WebDav, Sharepoint) vorhanden sein, der die Bearbeitung direkt erlaubt.
  • Atomare Dateien
    Mit dem Verzicht auf eine Datenbank o.ä., ist jede einzelne Datei quasi in sich abgeschlossen. Es ist für mich aber auch jeden Admin sehr einfach eine DOCX-Datei mit per Zwischenablage eingefügte Bilder zu erstellen und zuzuschneiden. Mit der passenden DOTX-Vorlage kann man die verwendbaren Formatierungen vorschreiben. Fehlt nur noch ein DOCX-Parser. Eine Versionierung so einer Datei ist über SharePoint, GitHub, u.a. einfach möglich.

Das hört sich alles schön aber aber es gibt durchaus eine kniffliger Komponente in diesem Bild: Die Verknüpfung von Seiten per Link. Wenn ich in Word oder einem anderen Programm eine Seite erstelle, dann kann ich dort relativ problemlos Links zu externen Seiten (URLs) addieren,. Aber Links zu internen Seiten sind etwas kniffliger herzustellen. Da im Editor keine "Seitenübersicht" da ist, müsste ich mit hier überlegen, entweder ebenfalls die externe URL einzupflegen oder vielleicht nur den eindeutigen "kurzen" Dateinamen oder den "Titel" der Seite. Die Generierung müsste dann basieren darauf den Link bei der Ausgabe erstellen. Knifflig hierbei natürlich die Aufgabe, wenn eine Seite umbenannt wird, um dann alle bestehenden Links nichts ins Leere laufen zu lassen. Hier ist SharePoint Designer einfach unschlagbar: Er aktualisiert einfach alle Seiten und Links, wen ich das Ziel verändere. Aber Herausforderungen sind dazu da, angegangen zu werden.

Schaubild der Komponenten

Nein, noch ist gar nichts davon "Life" oder angefangen. Es gibt erst mal nur viele Ideen, die geprüft und mehrfach überschlafen werden. Aber ich könnte mir folgendes vorstellen:

In der Mitte gibt es drei große Blöcke:

  • Dokumentspeicher A
    Herzstück ist ein "Dokumentspeicher A", in dem alle Dokument als einzelne Seiten im DOCX-Format vorliegen. Dieser Speicher kann ein einfacher Dateipfad, eine Sharepoint Bibliothek oder anderes Ablagesystemsein. Wichtig ist, dass dort drin die Quelldokumente ohne Formatierungen oder Hyperlinks einfach vorliegen. für die Formatierung sorgt eine Wordvorlage, die nur bestimmte "Styles" zulässt und jede manuelle Formatierung unterbindet. Denkbar ist hier jedes Ablagesystem wie ein Filesystem, Sharepoint Library oder auch GIT.
  • Generator B
    Die "DOCX-Dokumente" sind quasi "formatneutral" und müssen zur Anzeige für den Betrachter konvertiert werden. Der universelle Betrachter ist natürlich ein Browser. Vielleicht schaffe ich es irgendwann, diese Konvertierung "on the Fly" zu realisieren aber dann muss der Webserver schon einiges arbeiten und es wäre keine statische Version mehr. In der ersten Stufe denke ich daher weiter an einen regelmäßig gestarteten Generierungsprozess oder er wird immer dann angetriggert, wenn im Dokumentspeicher A eine Änderung erfolgt. Natürlich wird dieser Prozess aus dem DOCX-Dateien "saubere" HTML-Dateien erstellen mit allen Hyperlinks etc. erstellen.
  • Dokumentspeicher C
    Hier liegen letztlich die generierten Dokumente, auf die jemand per Browser über einen beliebigen Client zugreifen kann. Wenn es wirklich statische Seiten sind, dann könnte die "Dokumentation" auch Offline genutzt werden. Stichwort "Desasterfall".

Um diese drei Blöcke gibt es einige Schnittstellen:

  1. Zugang per Mail
    Sie glauben gar nicht wie viele Dokumente mit einer Mail starten. Mit Outlook ist es sehr einfach und schnell möglich in einer Mail mit Title, H1-H3, uL und OL und anderen "Styles" zu arbeiten und eine "Rohdokumentation" samt Bildern zu erstellen. Ich sehe es durchaus als legitimen Weg an, so eine "Seite" der Dokumentation initial zu erstellen und in das System einzustellen.
  2. Skript
    Ebenso könnten PowerShell-Skripte und andere Lösungen bestimmte Seiten "automatisch" generieren, z.B. Liste der AD-Standorte, Subnetze, Exchange Datenbanken, Connectoren, Serverdatenblatt, Serverliste etc. Ich habe mit den Reportweb schon erste Ansätze, aber diese werde ich nicht weiter aufbohren. Wenn die Skripte aber einfach nur einen trivialen HTML-Output erzeugen müssen und dann dieser Teil diese in die Dokumentation einbindet, wird die Lösung rund
  3. DOCX-Editor
    Natürlich müssen Dokumente auch mal überarbeitet werden. Hierzu sehe ich wieder Word mit direktem Zugriff auf die DOCX-Dateien als Mittel der Wahl. das könnte sogar "online" über WordApp funktionieren und damit den Zugang auch Online einfach erlauben.
  4. DOTX
    Damit die Autoren nicht "wild" Formatierungen verwenden, die später beim Konvertieren nach HTML stören, wird eine Word-Vorlage bereit gestellt, die nur bestimmte Formate zu lassen. Ich arbeite schon sehr lange mit Dokumentvorlagen und beim Schreiben des Buch zu Exchange 2003 habe ich dank der Vorlage des Hanser Verlags noch einmal viel hinzu gelernt, wie effektiv man mit Word arbeiten kann.
  5. Generator
    In der ersten Version wird sicher ein manuell oder als Task aufgerufener Planer die Dokumente lesen, Metadaten (Autor), Keywords etc.) sammeln und dann das Ziel erstellen. Später könnte er getriggert laufen oder die Generierung erfolgt generell beim Zugriff durch den Client.
  6. Ablage im HTML-Store
    Aktuell bin ich weiter davon überzeugt, dass eine statische generierte Seite in vielen Fällen am sichersten, einfachsten, probabelsten und universellsten ist. Die MSXFAQ hat aktuell kaum die Anforderung "dynamisch" zu sein und warum sollte daher ein WebServer mit PHP, ASPX o.ä. für jeden Zugriff den immer gleichen Inhalte neu generieren? Für eine Nachrichtenseite oder individualisiertes Portal sieht es sicher anders aus, aber ich habe nicht vor, dass die Nutzer sich an der MSXFAQ anmelden oder Cookies oder JavaScript nutzen müssen.
  7. Link zu Editor
    Auch wenn ein Autor per Browser die Datei betrachtet, kann sich dort ein Link zum "Bearbeiten" finden, der dann aber wieder auf die Worddatei verweist, d.h. lesen im Browser und bearbeiten in Word oder WordApp
  8. Betrachter
    Wer nicht editieren kann oder darf, liest die Dokumentation einfach "online" oder als HTML-Kopie.

Warum Word und DOCX

Warum Word?: Weil es ein sehr guter Editor ist, DOCX recht einfach automatisiert verarbeitet werden kann und zukünftig auch mit WordApp eine Browser und APP-Variante zur Verfügung steht. Denkbar wäre natürlich auch LibreOffice o.ä. Es muss dem "Autor" einfach gemacht werden, schnell und formatsicher ein Dokument zu erstellen oder zu verändern. Mit dem passenden Backend können sogar mehrere Personen an den gleichen Dokumenten arbeiten und Versionen gepflegt werden. Und letztlich erwarte ich von Word eine deutliche Beständigkeit gegenüber HTML-Editoren. Sharepoint Designer 2013 ist gar kein Editor mehr, der Live Writer ist auch beschränkt und ein fremdes Werkzeug macht es auch nicht besser. Word wird in der Lösung ja wirklich nur als einfacher Editor ohne Firlefanz (keine Kopf/Fußzeilen, kein Inhaltsverzeichnis o.a.) eingesetzt.

Ich bin aber gar nicht auf DOXC festgelegt. Letztlich ist es eine Frage des Konverters, welche Quellformate er einlesen kann. RTF wird genauso gerne genommen und natürlich auch sauberes HTML. Ich würde bei allen Quellformaten aber komplett darauf verzichten mit Formatierungen bezüglich Schrift o.ä., zu arbeiten sondern konsequent nur die Objekte als Überschrift, Aufzählung, Bild etc. zu klassifizieren und die Formatierung dann als Stylesheet ausgelagert anzuwenden.

Und warum kein Wiki, Blog, CMS ?

Die Frage ist berechtigt, denn Wikipedia macht es ja vor, wie Millionen Autoren gemeinsam Wissen schaffen und aktualisieren und Hyperlinks schon angelegt werden können, obwohl die Zielseite noch nicht vorhanden ist. Aber die meisten Administratoren haben Vorbehalte gegen Wikis, weil die Editor-Syntax den meisten "fremd" ist, Hyperlinks nicht dynamisch erstellt werden und dahinter dann doch wieder eine Datenbank o.ä. genutzt wird.

Für mich kommen aktuell Lösungen nicht in Frage, bei denen man nur Online und im Browser editieren kann. Da ich überwiegend alleine an der MSXFAQ schreibe und das auch unterwegs in Hotels, im ICE oder in Wartebereichen passiert, ist der Schritt noch zusätzlich Online sein zu müssen, einfach ein Hindernis. Ich habe sogar eine UMTS-Karte im Notebook und dennoch ist die Realität eben noch anders. Interessant wäre schon eine Synchronisation oder Ein/Aus-Checken.

Aber vor allem ist für mich ein Browser das denkbar schlechteste System zur Verwaltung von Webseiten. Wer schon mal zwischen Word und WordApp die Wahl hatte, wird verstehen, warum ich lieber mit einem "richtigen" Editor wie SharePoint Designer arbeite statt mit einem Browser als Editor. Auch wenn ich zugeben muss, dass die Browser immer leistungsfähiger werden. Aber schon das Einfügen von Bildern ist da noch sehr ineffektiv gelöst. Letztlich kann die MSXFAQ nur weiter leben, wenn ich möglichst effektiv den Inhalt ändern, korrigieren und erweitern kann.

Web Generatoren, GitHub und Co

Anscheinend gibt es sogar schon ähnliche Lösungen, wie meine Überlegungen. Aufgefallen ist mir das beim Blick auf https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/. Hier gibt es tatsächlich ein "Edit in GitHub".

 

Auf GIT-Hub können diese Dateien dann Online aber auch mit der "Desktop-Version" (https://desktop.GitHub.com/) bearbeitet werden. GitHub ist ja eine verteilte Versionsverwaltung und Code-Verwaltung. Vielleicht ist das ja schon ein Anknüpfungspunkt. Auch viele Editoren wie Visual Studio Code können direkte GIT nutzen

Dass ich mit meinen Überlegungen nicht "alleine" bin, habe ich im Sommer 2016 gesehen, weil es einige andere sehr interessante Projekte gibt, die vielleicht auch eine zukünftige Plattform für die MSXFAQ sein könnten:

Es gibt also durchaus andere Personen, die hier auch schon an "Generatoren" arbeiten.

Der Konvertierungsprozess

In der Quelle liegen einfach Unmengen an DOCX-Dateien. Das Ziel ist, dass jedes Thema in einem Dokument beschrieben ist, in dem es maximal eine "H1-Überschrift" gibt. Es sollte also in sich abgeschlossen sein und kann über verschiedene Wege "ankommen". Die Konvertierung beschränkt sich aber nicht allein auf die Umwandelung in HTML, sondern wird in mehreren Schritten folgende Aktionen durchführen:

  1. Sammeln der "Keywords", Schlüsseltexte, Überschriften (Dazu sollten H1 und H2 Überschriften natürlich "eindeutig" und Als Sprungziel deklariert sein, damit man darauf direkt Links erzeugen kann.,
    Da im Laufe der Generierung automatisch Links zu Seiten erstellt werden sollen
  2. Konvertieren aller Seiten mit Anpassen der Links

Wenn es wirklich jemand bis hierher gelesen hat und immer noch interessiert sind oder sogar Vorschläge und Hinweise auf passende Programme und Tools haben, dann freue ich mich über Hinweise z.B. per Mail (Kontakt)

Dokumentation wird in dem Maße erstellt, wie ich bei der Umsetzung vorab kommen.

Es gibt sogar einige Tools und Skripte, um "Docx" etc. zu konvertieren. Hier erst mal eine unkommentierte Link-Sammlung:

Ein bisschen Dynamik

An einigen Stellen würde ich mir natürlich schon etwas mehr "Dynamik" wünschen. Folgende Funktionen wären zu beleuchten, die aber wohl nicht ohne "aktive Komponenten", d.h. Serverseitige Skripte und Datenbanken möglich wären. Man könnte Sie aber vielleicht doch "ausgelagert" betreiben und nur einbinden. Damit wäre die MSXFAQ und jede ähnlich erstellte Seite weiterhin statisch und auch auf Servern oder Offline nutzbar.

  • Rating
    Sie kennen sicher die 0-5 Sterne-Klassifizierung von Seiten. Ich könnte es schon interessant finden, wenn Sie als Leser über Sterne die Qualität einer Seite bewerten können. So kann ich veraltete oder sogar unpassende Inhalte einfacher erkennen und auch andere Leser können interessante Seiten besser finden. Das lässt sich aber auch extern hosten, z.B. http://rating-widget.com/
  • SiteSuche
    Eine Volltextsuche innerhalb der MSXFAQ wäre schon sehr hilfreich. Ich selbst suche einfach nach Artikeln, in dem ich "MSXFAQ" oder "host:msxfaq.de" mit als Suchbegriff eingebe und damit sehr gut filtere.
  • Kommentare
    So gerne ich meinen Lesern die Möglichkeit einräumen würde, Kommentare zu hinterlassen, so kritisch stehe ich solchen Funktionen gegenüber. Ein offenes Forum kann ich hinsichtlich der Besucheranzahl und zu erwartenden Meldungen gar nicht zeitnah bedienen. Wenn aber Kommentare nicht zeitnah beantwortet werden oder an der Seite erscheinen, dann führt das auf beiden Seiten wohl sehr schnell zu Verdruss. Daher habe ich diese Funktion nicht auf meiner Wunschliste und vertraue darauf, dass wie bisher die Leser mit einfach eine Mail schreiben.
    Hier kann man aber auch externe Anbieter wie z.B. Disqus mit einbinden.
  • Benachrichtigung
    RSS-Feeds, Twitter, Facebook und Co nutze ich schon, um Sie über neue oder umfangreich geänderte Seiten zu informieren. Ich wünsche mir bei anderen Seiten oft eine Funktion über Änderungen dieses Seite informiert zu werden. Aber letztlich wird sich auch das nicht sinnvoll bereit stellen lassen, da auch hier der Server wieder "aktiv" werden müsste. Insofern sollten Sie einfach die Liste der Änderungen oder den RSS-Feed überwachen.

Weitere Links