Why is Special:Wantedpages not updated in Wikimedia sites since 3 September? If
it is too expensive to generate it in large wikis (especially enwiki), could it
be re-enabled for smaller wikis?
Thanks.
[breaking thread here]
On Jan 18, 2008 4:18 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:
> and
> -- if necessary, for heavy-weight stuff -- Java. All of these are
> free and open-source except Java, which still has some proprietary
> components that Sun has pledged to get rewritten as open-source (so
> that's not *quite* ideal, but hopefully getting there).
Positive news on the Java front: Although Sun hasn't finished all the
stuff they have pledged, independent parties have combined the freely
released Sun material with the open source reimplementations of Java
to produce a fully boot-strapable nearly-complete environment. It even
includes the ability to run untrusted web-applets, which was not
really possible in the free reimplimentations because they lacked the
Java security infrastructure.
Fedora 8 includes this IcedTea java environment
(http://fedoraproject.org/wiki/Interviews/ThomasFitzsimmons), which
I've found works quite well. (Amusingly, Cortado, the Java player on
Wikimedia sites has problems for me ... Though it ran fine in the free
GCJ environment)
Not that I think we should go headlong into using java. There are many
good arguments against having most than the absolute minimum of
executable code launched from our pages. Accessibility for the
disabled, client compatibility, client performance issues (and
accessibility to people on computers of limited performance),
maintance and longevity issues, compatibility with non-web mediums
(print, etc). I won't belabor this further, since we've discussed this
before.
It just means that the freeness issues of Java are much less than they
were a few months ago, so we're close to one less issue out of an
expansive set.
I'd like to see robust, complete, and fully free licensed Java
installs for Windows/Mac which we could redistribute ourselves if we
wanted, and which we could reasonably expect people to be using as
their normal Java environments before I'll concede that Java's
freeness issues are gone entirely, but that really does seem within
reach now.
Simultaneous send to wikitech-l, foundation-l, and commons-l
Hi folks,
Yesterday the Wikimedia Foundation, Kaltura, and WikiEducator made a
combined announcement about our beta collaborative video project. You
can see the announcement here:
http://wikimediafoundation.org/wiki/Wikipedia_Invites_Users_to_Take_Part_in…
The Foundation has set up a landing page here:
http://wikimediafoundation.org/wiki/Collaborative_Video
with more background and information. We'll keep it updated regularly.
WikiEducator has done the same here:
http://wikieducator.org/Help:Collaborative_video
with specific instructions on how to participate in the beta.
Through this project the parties will be able to explore the potential
for developing open-source, collaborative video or slideshows for the
Foundation's projects. Collaborative video is simply a collection of
images, video, and sound edited and combined by one or more collaborators.
The technology, which many of you may already be familiar with, will be
demonstrated on WikiEducator - which is not a WMF project. Those of us
involved in the Wikimedia Foundation projects will have a chance to
examine the software, test its limits, and ultimately improve our
ability to bring multi-media, free knowledge content to our users. We
recognize that Kaltura's software and interface are still not 100%
open-source, and as such the technology will not appear on any
Foundation projects until we've worked through some of the technical
challenges - which is where you come in.
Kaltura has released their code to the open-source community to help
this project along. It's available on SourceForge,
http://sourceforge.net/projects/kaltura .
We're excited that an innovative, private business has taken strong
initiative in embracing open-source development.
You're invited to examine the code, test the technology as it exists on
WikiEducator, and help us bring this functionality to the Wikimedia
Foundation projects over the coming months. You'll find a feedback
process on the WikiEducator landing page, and of course we fully welcome
discussion about the technology on the lists.
Thanks,
--
Jay Walsh
Head of Communications
WikimediaFoundation.org
1 (415) 287-0680
When we were just having those stale-cache issues, with
redirected pages and the like, it seemed that you got a
consistently stale page, not the randomly stale page you'd expect
if each refresh got you a different squid server with a different
stale version of the page. Moreover, the effect seemed to be
browser-dependent: you could open two different browsers on the
same redirected page, refresh each browser several times, and the
two browsers would consistently get the same two *different*
consistently stale pages.
Do the load balancers in WMF's server farms attempt to associate
sessions with servers? At first I thought this unlikely, but I
guess it could significantly improve the hit rate.
On Jan 18, 2008 3:52 PM, <daniwo59(a)aol.com> wrote:
> Further confusion from the Terms of Service
> (http://www.kaltura.com/index.php/cms/signup)
>
> The content on the Kaltura Website, except all User Submitted Media (as
> defined below), including without limitation, the text, software, scripts,
> graphics, photos, sounds, music, videos, interactive features and the like
> ("Content") and the trademarks, service marks and logos contained therein
> ("Marks"), are owned by or licensed to Kaltura, and is subject to copyright
> and other intellectual property rights under United States and foreign laws
> and international conventions.
If they don't want to free their website that shouldn't be an issue.
> You agree to not engage in the use, copying, or distribution of any of the
> Content other than expressly permitted herein, including any use, copying,
> or distribution of User Submitted Media of third parties obtained through
> the Website for any commercial purposes.
>
> You agree not to circumvent, disable or otherwise interfere with security
> related features of the Kaltura Website or features that prevent or restrict
> use or copying of any Content or enforce limitations on use of the Kaltura
> Website or the Content therein.
So the "you may not copy the user contributed media for commercial
purposes" fits hand-in-hand with the CC-*-NC license Kaltura was using
until Wikimedia asked them to use CC-By-SA instead (I hear that this
was due to Brianna pointing out the baddness of pushing NC on
everyone? If so thanks!). There are a number of places where NCisms
still exist on their site.
Probably some or most of these should be cleaned up, although "We can
use your stuff, people can download it personally, but a competitor
can't mirror our site" is a primary attraction of -NC licenses on
Web2.0 user-exploitive content sites, and is probably something to
keep and eye on and make sure is completely resolved.
I'll leave boggling whole notion of them unilaterally changing the
licensing of all their pre-existing user contributed content
(apparently without notice) as an exercise for the reader.
The DRMish clause is nasty. Right now Kaltura creations are
inexorably tied into their software (no export, it's rendered on the
fly by flash on the client), so it's already a pretty effective DRM.
This could easily be arguably be expressly against the CC-by-sa
license grant which forbids the use of technological measures for the
purpose of restricting the content, however, another TOS clause you
failed to copy dispenses with that concern:
"By submitting the User Submitted Media to Kaltura, you hereby grant
Kaltura and any of its affiliates a worldwide, non-exclusive,
royalty-free, sublicenseable and transferable license to (i) host,
cache, store, archive, index, crawl, create algorithms based on,
modify or transcode the User Submitted Media to appropriate media
formats, standards or mediums as part of the Kaltura Website; (ii) to
use, reproduce, distribute, prepare derivative works of, display,
modify, remix, excerpt, adapt or transcode the User Submitted Media to
appropriate media formats, standards or mediums as part of the Kaltura
Website and perform the User Submitted Media in connection with the
Kaltura Website and Kaltura's (and its successor's) business,
including without limitation for promoting and redistributing part or
all of the Kaltura Website (and derivative works thereof), or in
connection with any distribution or syndication arrangement thereof
with third parties or third-party sites, in any media formats and
through any media channels; (iii) to use User Submitted Media for and
in connection with advertising, promotional or commercial purposes,
including without limitation, the right to publicly display, perform,
reproduce and distribute the User Submitted Media in any media format
or medium and through any media channels; (iv) Kaltura reserves and
has the right to sell, license and/or display any advertising,
attribution, links, promotional and/or distribution rights in
connection with User Submitted Media, and Kaltura will be entitled to
retain any and all revenue [snip]"
While an expansive "we get a special right to exploit your content
above and beyond any licensing you've granted the world, just because
you were enough of a sucker to upload it here" may be common place on
Web2.0 sites, I don't think it's ethical, I don't think it's
beneficial to the world of free content, and I don't think it's the
sort of behavior Wikimedia should have anything to do with.
It's quite possible that Kaltura will gladly fix these issues, since I
understand they were responsive to requests prior to the release going
out ... So while unfortunate there may not currently be any cause for
alarm.
Message mode (output type OT_MSG in the parser) was only meant to replace
variables like {{SITENAME}} and parser functions like {{NS:4}}, it was
never meant to allow templates. It's a very commonly called code path, and
I wanted it to be efficient. Unfortunately, due to a bug apparently
present since my initial version of the code, it did allow templates at
the first level of recursion only. However, because various points in the
code assumed that they weren't allowed, they were broken in various ways,
such as the fact that triple-brace arguments aren't recognised and don't work.
In September 2004 in r5477, a second transformMsg() call was added to the
output path of wfMsg(). transformMsg() is called once in
MessageCache::getMessage(), and again in wfMsgGetKey() (originally
wfMsgReal). So all messages containing double braces (except ones
retrieved with wfMsgExt) are double-parsed.
Apparently nobody noticed this except for the users, who began to add a
second level of template recursion to their messages, now enabled by the
double-parse.
I had a half-hearted go at reproducing the oddities of message mode in the
new preprocessor, but inevitably, there are some changes. If we're going
to have changes, we may as well go the whole hog.
I propose removing message mode, which obviously has never been reviewed
or tested properly, and replacing it with preprocess mode. So instead of
calling transformMsg() twice, messages will be transformed by calling
preprocess() once.
Preprocess mode at least gets some eyeballs on it due to its use in
Special:ExpandTemplates, where there is a strict expectation of
consistency with HTML mode. It works in a reasonably intuitive way:
templates and template arguments work in basically the same way as in HTML
mode, it's just XML-style extensions that get skipped.
-- Tim Starling
Hi!
As so many I am also trying to fix some sort of single sign-on for several services. My situation: I get an encrypted username and password from another website, decrypt it and than want to authenticate and/or create the user exactly as is done through the regular login form (behind which in my case an Ldap plugin is doing its magic). I was hoping you guys could put me on the right track. I tried many things much like the following (which obviously runs into many errors).
<?php
require_once('includes/SpecialUserlogin.php');
require_once('includes/AuthPlugin.php');
require_once('includes/WebRequest.php');
define('MEDIAWIKI', true);
require_once('LocalSettings.php');
$wgRequest = new FauxRequest( array (
'wpName' => 'username', // dynamically filled
'wpPassword' => 'password', // dynamically filled
'wpDomain' => 'MYDOMAIN',
'wpRemember' => '1',
'wpLoginattempt' => 'Log in',
'returnto' => 'Main_Page', // dynamically filled
));
$form = new LoginForm( $wgRequest );
$form->execute();
?>
Do I need to create another object (AuthPlugin?) or use the $wgAuth somehow? A little push in the right direction would be greatly appreciated. Using the mediawiki Api (ApiLogin.php) I can authenticate but I do not know how to use this further.
Sorry for my ignorance but I do not seem to be able to read the php of mediawiki well enough to provide the solution myself. Browsing the wiki's, googling and searching this mail list has so far not helped.
Kind regards,
Jac (Istanbul, Turkey)