https://bugzilla.wikimedia.org/show_bug.cgi?id=4582
--- Comment #242 from Philippe Verdy <[EMAIL PROTECTED]> 2008-11-26 23:00:01 UTC --- That's simple: if you implemented user-specific data formatting, keep the syntax you have adopted for Wiki, but make it generate a generic format that will be handled now with Javascript (and well, ignore anonymous users without preferences in some user account...). Anyway, I have made some other suggestions on Madiawiki to help servers reduce the load of Wikimedia Squid caches and PHP servers. Basically, it's time to think about creating a locally deployable proxy version of the MediaWiki software, implementing the PHP MediaWiki PHP code, the PHP engine and the web server, and also working as the proxy that a local browser (or a new dedicated MediaWiki browser with extra editing tools) could connect to instead of connecting directly to the online service. I suggested that this type of deployment cuold also be part of a CD/DVD distribution and would allow eliminating the need to preview before sending edits. Instead I spoke about the possibility of the locally deployed proxy to be able to have its own local cache, communicating with the online server only with pages in raw format (much less load on Wikimedia PHP servers, because much less work to do in PHP for formatting pages, just the need to manage the history and control the access rights, and the possibility to inform the conencted users about incoming messages). The locally deployed proxy would be able to load pages from a locally installed database (from a dump stored on a CD/DVD or downloaded onto a harddisk) and filter out the edits made by the local user(s) that could mange a queue of updates to send (in a private, corporate or shoold environment, it would be possible to support a supervizion for pages sent/edited from the local network through the proxy storing the list of locally edited pages, if local users are not directly granted the right to commit their pages online without permission or basic monitoring anf history. I spoke also about the fact that this would also allow Wikipedia and similar collaborative projects to be able to better control the level of vandalism made mostly anonymously from school/university networks (no more need to ban the entire school or university, if it has firewalled Wikiemdia servers but routed them through a MediaWiki proxy managing the supervision: the school or corporate network would be able to submit updates through public online accounts managed by supervizors that are contactable and can act locally about the vandalism or breach of copyright by one of their supervized local users (that may be connected to the local proxy using a strong and verifiable identity that does not need to be transmitted online, so it can also improve their online privacy). Finally, the whole set: a dedicated MediaWiki browser application and a local proxy could become the prefered way to work with Wikipedia: all would be integrated including the management of the submission queue and a local supervizion of the queue by the user itself, managing himself the pririty of queues. As it would embed a local cache, it would perform much less traffic with the online server. The Wikimedia's Squid proxies would still be used, but onlyto cache the much smaller raw pages instead of the large HTML pages. The Wikimedia's own MEdiaWiki servers would also see much less traffic and would caould satisfy more users with limited local cache of pre-generated HTML pages (without the user-specific additions like messages), because all locally deployed proxies would only communicate with them in raw format. So that's a way to control for a longer term the problem of the explosion of traffic and of server costs to manage this traffic. You would not necessarily need the same explosion in terms of number of squid servers needed to cache the full HTML pages (they would still be needed to cache the images, because, by default, the image thumbnails should be generated centrally and cached centrally to avoid sending them always in full resolution to every user of a proxy version of MediaWiki... Well all this goes too far way from the current problem of date formatting. I realize that the fact you have eimplemented it is causing problems wiith more traffic generated, but it should be easily reverted before its use becomes widespread, or the onli ne preformances will suffer. I suggest the simple solution of generating a single HTML code for your existing syntax, and then let a Javascript gadget perform the actual formatting. Your squid servers will appreciate ! -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
