Hello all,
at the moment it is difficult to inform our toolusers (people that use our tools) about planed maintainces, downtimes and other important things.
So I had the idea today that a kind of global sitenotice (like the one in the wikimedia-projects) would be nice and a easy solution for that. The easiest way to implement it is IMHO a simple textfile, that toolauthors may/can/should/whatever insert in their tools. I created such a file, it can be found at /var/www/sitenotice on wolfsbane and via http://toolserver.org/sitenotice. For normal the file would be empty or contains only a empty div-container. If the roots know about a planed downtime or an important change, they would insert a short text in the file and our toolusers would be informed.
The setup is differend to status.toolserver.org, because status lists only the current status, not a futuraly status.
Please comment at the toolserver-mailinglist and tell me/us if you would implement the sitenotice in your tools.
Sincerly, DaB.
On Sun, Aug 16, 2009 at 17:35, DaB.WP@daniel.baur4.info wrote:
The easiest way to implement it is IMHO a simple textfile, <...> I created such a file
Please don’t enforce any markup or formatting, it should be up to tools’ authors. It should be simply text.
— Kalan
2009/8/16 DaB. WP@daniel.baur4.info:
true. But what is the problem of an div-container with an id? And it would be nice (IMHO) to have the possibility to add a url that links to further informations, wouldn't it?
no problem, it'd be nicer if you could make sure it's valid XML too, then tool authors wanting to extract the message can do so easily, as well as being able to just include the html fragment into their tools.
Regards,
Simon Walker User:Stwalkerster on all public Wikimedia Foundation wikis Administrator on the English Wikipedia Developer of Helpmebot, the ACC tool, and Nubio 2 FAQ repository
2009/8/16 Simon Walker stwalkerster@googlemail.com:
2009/8/16 DaB. WP@daniel.baur4.info:
true. But what is the problem of an div-container with an id? And it would be nice (IMHO) to have the possibility to add a url that links to further informations, wouldn't it?
no problem, it'd be nicer if you could make sure it's valid XML too, then tool authors wanting to extract the message can do so easily, as well as being able to just include the html fragment into their tools.
I've incorporated this message into my index page: http://toolserver.org/~holek/index.php So I'd like to know about any changes to it. :)
DaB. wrote:
Hello all,
at the moment it is difficult to inform our toolusers (people that use our tools) about planed maintainces, downtimes and other important things.
So I had the idea today that a kind of global sitenotice (like the one in the wikimedia-projects) would be nice and a easy solution for that. The easiest way to implement it is IMHO a simple textfile, that toolauthors may/can/should/whatever insert in their tools. I created such a file, it can be found at /var/www/sitenotice on wolfsbane and via http://toolserver.org/sitenotice. For normal the file would be empty or contains only a empty div-container. If the roots know about a planed downtime or an important change, they would insert a short text in the file and our toolusers would be informed.
The setup is differend to status.toolserver.org, because status lists only the current status, not a futuraly status.
Please comment at the toolserver-mailinglist and tell me/us if you would implement the sitenotice in your tools.
I think this would be a good idea. I've actually been considering something like this for my tools. My idea was to use multiple files. One would be for issues that would affect every tool, like if the webserver was going to be down. Others would be for issues that may only affect a couple tools, like one of the DB-servers being down, or high replag on a server. That way tools that don't need DB access or aren't significantly affected by high replag won't have unnecessary notices but the tools that do need it can still have the notice.
For things like replag, the notice wouldn't even need to be changed by a person, there could just be a script run every few minutes that would automatically add the notice to the file if replag was > N seconds.
On Sun, Aug 16, 2009 at 5:04 PM, Alex mrzmanwiki@gmail.com wrote:
I think this would be a good idea. I've actually been considering something like this for my tools. My idea was to use multiple files. One would be for issues that would affect every tool, like if the webserver was going to be down. Others would be for issues that may only affect a couple tools, like one of the DB-servers being down, or high replag on a server. That way tools that don't need DB access or aren't significantly affected by high replag won't have unnecessary notices but the tools that do need it can still have the notice.
Why so difficult? Put it into a div structure:<div id="notice"> <!-- *global* stuff goes here --> </div> <div id="notice-s1"> <!-- *s1* related stuff goes here --> </div> <div id="notice-s2"> <!-- *s2* related stuff goes here --> </div> <div id="notice-s3"> <!-- *s3* related stuff goes here --> </div>
This way you can selectively choose to display the status of components relevant to the specific tool.
Marco
Marco Schuster wrote:
On Sun, Aug 16, 2009 at 5:04 PM, Alex <mrzmanwiki@gmail.com mailto:mrzmanwiki@gmail.com> wrote:
I think this would be a good idea. I've actually been considering something like this for my tools. My idea was to use multiple files. One would be for issues that would affect every tool, like if the webserver was going to be down. Others would be for issues that may only affect a couple tools, like one of the DB-servers being down, or high replag on a server. That way tools that don't need DB access or aren't significantly affected by high replag won't have unnecessary notices but the tools that do need it can still have the notice.Why so difficult? Put it into a div structure:
<div id="notice"> <!-- *global* stuff goes here --> </div> <div id="notice-s1"> <!-- *s1* related stuff goes here --> </div> <div id="notice-s2"> <!-- *s2* related stuff goes here --> </div> <div id="notice-s3"> <!-- *s3* related stuff goes here --> </div>
This way you can selectively choose to display the status of components relevant to the specific tool.
Marco
I considered that as well, but figured it would likely be more difficult. It'll require every tool that uses it to have an extra stylesheet to hide all the notices that shouldn't be displayed. Additionally, it means the notice is going to be constantly filled with half a dozen empty divs, or the people updating it will have to remember what IDs to use for each notice.
Alex schrieb:
Marco Schuster wrote:
On Sun, Aug 16, 2009 at 5:04 PM, Alex <mrzmanwiki@gmail.com mailto:mrzmanwiki@gmail.com> wrote:
I think this would be a good idea. I've actually been considering something like this for my tools. My idea was to use multiple files. One would be for issues that would affect every tool, like if the webserver was going to be down. Others would be for issues that may only affect a couple tools, like one of the DB-servers being down, or high replag on a server. That way tools that don't need DB access or aren't significantly affected by high replag won't have unnecessary notices but the tools that do need it can still have the notice.Why so difficult? Put it into a div structure:
<div id="notice"> <!-- *global* stuff goes here --> </div> <div id="notice-s1"> <!-- *s1* related stuff goes here --> </div> <div id="notice-s2"> <!-- *s2* related stuff goes here --> </div> <div id="notice-s3"> <!-- *s3* related stuff goes here --> </div>
This way you can selectively choose to display the status of components relevant to the specific tool.
Marco
I considered that as well, but figured it would likely be more difficult. It'll require every tool that uses it to have an extra stylesheet to hide all the notices that shouldn't be displayed. Additionally, it means the notice is going to be constantly filled with half a dozen empty divs, or the people updating it will have to remember what IDs to use for each notice.
Don't think too much in html. Some tools won't produce HTML but RSS, XML, TEXT, PDF or sth. How are they supposed to handle this? I'll opt for simple & plain text.
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
Don't think too much in html. Some tools won't produce HTML but RSS, XML, TEXT, PDF or sth. How are they supposed to handle this? I'll opt for simple & plain text.
i agree, and i've converted the file to plain text. (apart from this issue, it seemed entirely pointless to put the <div> in the file; if people want to include it in a <div>, they can do it themselves.)
i can't see any need for markup except <a>, to allow URLs to have shorter link text. perhaps some markup could be added for this, e.g. [http://example.com link text] from MediaWiki. it would still be readable unparsed, and if necessary, it should be trivial to write a library for the most common language to convert it to HTML.
- river.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner wrote:
Alex schrieb:
Marco Schuster wrote:
On Sun, Aug 16, 2009 at 5:04 PM, Alex <mrzmanwiki@gmail.com mailto:mrzmanwiki@gmail.com> wrote:
I think this would be a good idea. I've actually been considering something like this for my tools. My idea was to use multiple
files. One
would be for issues that would affect every tool, like if the
webserver
was going to be down. Others would be for issues that may only
affect a
couple tools, like one of the DB-servers being down, or high
replag on a
server. That way tools that don't need DB access or aren't
significantly
affected by high replag won't have unnecessary notices but the tools that do need it can still have the notice.Why so difficult? Put it into a div structure:
<div id="notice"> <!-- *global* stuff goes here --> </div> <div id="notice-s1"> <!-- *s1* related stuff goes here --> </div> <div id="notice-s2"> <!-- *s2* related stuff goes here --> </div> <div id="notice-s3"> <!-- *s3* related stuff goes here --> </div>
This way you can selectively choose to display the status of components relevant to the specific tool.
Marco
I considered that as well, but figured it would likely be more difficult. It'll require every tool that uses it to have an extra stylesheet to hide all the notices that shouldn't be displayed. Additionally, it means the notice is going to be constantly filled with half a dozen empty divs, or the people updating it will have to remember what IDs to use for each notice.
Don't think too much in html. Some tools won't produce HTML but RSS, XML, TEXT, PDF or sth. How are they supposed to handle this? I'll opt for simple & plain text.
Peter
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette Same here, I'd rather have a file for each server; empty when everything is running as it should, and with an error when it isn't. Having an empty div inside would force toolmakers to check the contents of the divs instead of just checking if the file contains any text or not.
Chris, aka. Bjelleklang
chris schrieb:
I'll respect that from now on. But you also did a "bottom post", wasn't it?
Peter
On Sun, Aug 16, 2009 at 11:10 PM, Peter Körnerosm-lists@mazdermind.de wrote:
chris schrieb:
I'll respect that from now on. But you also did a "bottom post", wasn't it?
That's an auto-added header added by Mailman. But yeah that was a bottom post.
Bryan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry about that, the link slipped in from the footer of the previous message. It wasn't directed towards anyone at all :)
Chris
Bryan Tong Minh wrote:
On Sun, Aug 16, 2009 at 11:10 PM, Peter Körnerosm-lists@mazdermind.de
wrote:
chris schrieb:
I'll respect that from now on. But you also did a "bottom post",
wasn't it?
That's an auto-added header added by Mailman. But yeah that was a
bottom post.
Bryan
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette
On Sun, August 16, 2009 8:31 pm, Fahad Sadah wrote:
Please consider making this file 666, so anyone can update the status, wiki-style?
<meta http-equiv="refresh" content="0;url=http://evilwebsite.evil">
No thanks. Wikis at least have some protection in the form of accountability and html-injection-preventions. A chmod 666 text file does not.
Just a plain text file please, or the output from a wiki page (i.e. by using https://wiki.toolserver.org/w/index.php?page=Main_Page&action=render or https://wiki.toolserver.org/w/api.php?action=parse&page=Main_Page)
-Merlijn
Victor Vasiliev wrote:
Are status_* files still updated regularly?
$ ls -l /var/www/status* lrwxrwxrwx 1 root root 10 2009-02-28 16:51 /var/www/status_s0 -> status_sql -rw-r--r-- 1 root root 805 2008-09-08 04:18 /var/www/status_s1 -rw-r--r-- 1 root root 847 2008-01-12 11:13 /var/www/status_s2 -rw-r--r-- 1 root root 977 2008-09-08 04:19 /var/www/status_s3 -rw-r--r-- 1 root root 654 2008-02-06 18:09 /var/www/status_sql
Maybe the people taking care of status.toolserver.org could set the status file to be copied to the toolserver whenever something is changed? It seems to be kept up to date fairly well, and it beats each tool author slowly answering requests on what's wrong, or people blaming every little problem on the entire toolserver's reliability.
The status files were a great idea, other than not being kept up to date. The status.toolserver.org content would be nice to have in a single file already, but even better would be to split it to status_<service> files, maybe using the previously introduced format. http://lists.wikimedia.org/pipermail/toolserver-l/2007-September/000910.html
On Mon, Aug 17, 2009 at 6:36 PM, parapara@sci.fi wrote:
Victor Vasiliev wrote:
Are status_* files still updated regularly?
Maybe the people taking care of status.toolserver.org could set the status file to be copied to the toolserver whenever something is changed?
Perhaps somebody should make a script that auto fetches status.toolserver.org and put it into the relevant status files. That should not be too hard and can be run from crontab.
Bryan
Hello, Am Montag 17 August 2009 20:32:42 schrieb Bryan Tong Minh:
Perhaps somebody should make a script that auto fetches status.toolserver.org and put it into the relevant status files. That should not be too hard and can be run from crontab.
I wrote such a script. It will become live when wolfsbane is converted.
Sincerly, DaB.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Il giorno 16/ago/09, alle ore 15:35, DaB. ha scritto:
Hello all,
at the moment it is difficult to inform our toolusers (people that use our tools) about planed maintainces, downtimes and other important things.
I agree.
So I had the idea today that a kind of global sitenotice (like the one in the wikimedia-projects) would be nice and a easy solution for that. The easiest way to implement it is IMHO a simple textfile, that toolauthors may/can/should/whatever insert in their tools. I created such a file, it can be found at /var/www/sitenotice on wolfsbane and via http://toolserver.org/sitenotice. For normal the file would be empty or contains only a empty div-container. If the roots know about a planed downtime or an important change, they would insert a short text in the file and our toolusers would be informed.
I would like only simple text, it's more flexible: on TS we've several kinds of tools, and not all of them output HTML.
Please comment at the toolserver-mailinglist and tell me/us if you would implement the sitenotice in your tools.
I've implemented this in my tools (e.g. http://toolserver.org/~pietrodn/intersectContribs.php) , here is the simple code I wrote down (in case it could be useful to someone):
function print_globalnotice() { $text = file_get_contents('/var/www/sitenotice'); if($text != '') { echo '<div id="globalnotice">' . $text . '</div>'; } }
And the CSS:
#globalnotice { border: 1px solid silver; background: lightyellow; padding: 3px; }
"I'm Outlaw Pete, I'm Outlaw Pete, Can you hear me?" Pietrodn powerpdn@gmail.com
toolserver-l@lists.wikimedia.org