Re: [Wikitech-l] Google Summer of Code: accepted projects

[Nikola Smolenski]

Wu Zhe wrote:
> Asynchronous daemon doesn't make much sense if page purge occurs on
> server side, but what if we put off page purge to the browser? It works
> like this:
> 
> 1. mw parser send request to daemon
> 2. daemon finds the work non-trivial, reply *immediately* with a best
>fit or just a place holder
> 3. browser renders the page, finds it's not final, so sends a request to
>daemon directly using AJAX
> 4. daemon reply to the browser when thumbnail is ready
> 5. browser replace temporary best fit / place holder with new thumb
>using Javascript
> 
> The daemon now have to deal with two kinds of clients: mw servers and
> browsers.

To me this looks way too overcomplicated. I suggest a simpler approach:

1. mw copies a placeholder image to the appropriate filename: the 
placeholder could be the original image, best match thumb or a PNG with 
text "wait until the thumbnail renders";
2. mw send request to daemon;
3. daemon copies resized image over the placeholder.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Wu Zhe]

Nikola Smolenski  writes:

> Wu Zhe wrote:
>> Asynchronous daemon doesn't make much sense if page purge occurs on
>> server side, but what if we put off page purge to the browser? It works
>> like this:
>> 
>> 1. mw parser send request to daemon
>> 2. daemon finds the work non-trivial, reply *immediately* with a best
>>fit or just a place holder
>> 3. browser renders the page, finds it's not final, so sends a request to
>>daemon directly using AJAX
>> 4. daemon reply to the browser when thumbnail is ready
>> 5. browser replace temporary best fit / place holder with new thumb
>>using Javascript
>> 
>> The daemon now have to deal with two kinds of clients: mw servers and
>> browsers.
>
> To me this looks way too overcomplicated. I suggest a simpler approach:
>
> 1. mw copies a placeholder image to the appropriate filename: the 
> placeholder could be the original image, best match thumb or a PNG with 
> text "wait until the thumbnail renders";
> 2. mw send request to daemon;
> 3. daemon copies resized image over the placeholder.

This simpler approach differs in that it gets rid of the AJAX thing, now
users have to manually refresh the page. Whether the AJAX is worth the
effort is discussable.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Magnus Manske]

I've created an initial proposal for a unified storage-handling database:

http://www.mediawiki.org/wiki/User:Magnus_Manske/File_handling

Feel free to edit and comment :-)

Cheers,
Magnus

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Jacopo Corbetta]

On Fri, Apr 24, 2009 at 05:59, Andrew Garrett  wrote:
> I'd like to look towards trimming some of the existing preferences
> that are no longer relevant, and adding new preferences as common
> sense dictates.

Can I suggest adding a "preferred editor" preference?
Ideally, it should be a dropdown box (given the variety of existing
visual editors 
,
an admin might wish to install more than one), but a simple "disable
the visual editor" checkbox is probably enough for most setups (and
simpler to maintain).

Thanks, bye
--
Jacopo Corbetta
j.corbe...@sssup.it
jacopo.corbe...@gmail.com

WYMeditor MediaWiki integration:
http://www.mediawiki.org/wiki/Extension:MeanEditor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Eugene Zelenko]

Hi!

On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett  wrote:
> The advantage of this clear separation is that writing an API module
> is very simple, and it can be called internally, too!

I think will be good idea to use API internally (not only have
possibility to call), as result code will have more testing and
coverage.

Eugene.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[John Doe]

thanks, I take this as the first step in creating global preferences?

On Fri, Apr 24, 2009 at 9:36 AM, Eugene Zelenko wrote:

> Hi!
>
> On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett 
> wrote:
> > The advantage of this clear separation is that writing an API module
> > is very simple, and it can be called internally, too!
>
> I think will be good idea to use API internally (not only have
> possibility to call), as result code will have more testing and
> coverage.
>
> Eugene.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Mohamed Magdy]

On Fri, Apr 24, 2009 at 5:59 AM, Andrew Garrett wrote:

> I've branch-merged the new preferences system that I've spent the last
> few weeks developing.
>
> On the outside, you probably won't notice any difference except a few
> bugfixes, but the internals have undergone a complete rewrite.
>
> All of the actual preference definitions and utility functions have
> been separated out into Preferences.php, which holds all business
> logic for the new system. The UI and submission logic for the system
> is done in SpecialPreferences.php, which, now only a hundred lines
> long, wraps a generic class I've written to encourage separation of
> business and UI logic called 'HTMLForm'.
>
> The advantage of this clear separation is that writing an API module
> is very simple, and it can be called internally, too!
>
> Extensions must now hook GetPreferences instead of the existing hooks
> (which were too low-level to maintain compatibility with), I've
> updated all extensions used on Wikimedia. This new hook allows you to
> put preferences wherever you want, and a new preference can be added
> in less than ten lines of code, rather than the hundred-line nightmare
> that was required in the previous iteration.
>
> I'd like to look towards trimming some of the existing preferences
> that are no longer relevant, and adding new preferences as common
> sense dictates.
>
> Feedback, praise and criticism regarding the changes is certainly welcome!
>
> --
> Andrew Garrett
> Sent from Sydney, Nsw, Australia
>
> ___
>

You are so useful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brian]

How many non-WMF extensions will this break?

On Thu, Apr 23, 2009 at 9:59 PM, Andrew Garrett wrote:

> I've branch-merged the new preferences system that I've spent the last
> few weeks developing.
>
> On the outside, you probably won't notice any difference except a few
> bugfixes, but the internals have undergone a complete rewrite.
>
> All of the actual preference definitions and utility functions have
> been separated out into Preferences.php, which holds all business
> logic for the new system. The UI and submission logic for the system
> is done in SpecialPreferences.php, which, now only a hundred lines
> long, wraps a generic class I've written to encourage separation of
> business and UI logic called 'HTMLForm'.
>
> The advantage of this clear separation is that writing an API module
> is very simple, and it can be called internally, too!
>
> Extensions must now hook GetPreferences instead of the existing hooks
> (which were too low-level to maintain compatibility with), I've
> updated all extensions used on Wikimedia. This new hook allows you to
> put preferences wherever you want, and a new preference can be added
> in less than ten lines of code, rather than the hundred-line nightmare
> that was required in the previous iteration.
>
> I'd like to look towards trimming some of the existing preferences
> that are no longer relevant, and adding new preferences as common
> sense dictates.
>
> Feedback, praise and criticism regarding the changes is certainly welcome!
>
> --
> Andrew Garrett
> Sent from Sydney, Nsw, Australia
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Alexandre Emsenhuber]

Le 24 avr. 09 à 16:15, John Doe a écrit :

> thanks, I take this as the first step in creating global preferences?

Global preferences were added with this rewrite. There is just a  
checkbox saying "use these preferences on all projects" at the bottom  
of Special:Preferences.

Alexandre Emsenhuber (ialex)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brian]

Is an autoconverter feasible?
There are many, many extensions guys!

On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett wrote:

> On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
>  wrote:
> > Hoi,
> > How much work do you think it will be to repair an extension that needs
> > repair ? For someone who knows the code and for someone who just has to
> > repair his one extension ??
>
> It's a reasonably simple fix. Here's an example: [1]
>
> Essentially, all you need to do is remove your existing preferences
> code, hook GetPreferences, and add your preference to the array. I'll
> be posting documentation as to the format of preference entries
> tomorrow, but for now you can look at the examples in
> includes/Preferences.php.
>
> [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690
>
> --
> Andrew Garrett
> Sent from Sydney, Nsw, Australia
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Chad]

And the vast vast majority don't use preferences. I don't think it'll
be a huge issue. The extensions that are broken and people use
will quickly be found and fixed.

-Chad

On Fri, Apr 24, 2009 at 12:43 PM, Brian  wrote:
> Is an autoconverter feasible?
> There are many, many extensions guys!
>
> On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett wrote:
>
>> On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
>>  wrote:
>> > Hoi,
>> > How much work do you think it will be to repair an extension that needs
>> > repair ? For someone who knows the code and for someone who just has to
>> > repair his one extension ??
>>
>> It's a reasonably simple fix. Here's an example: [1]
>>
>> Essentially, all you need to do is remove your existing preferences
>> code, hook GetPreferences, and add your preference to the array. I'll
>> be posting documentation as to the format of preference entries
>> tomorrow, but for now you can look at the examples in
>> includes/Preferences.php.
>>
>> [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690
>>
>> --
>> Andrew Garrett
>> Sent from Sydney, Nsw, Australia
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 12:31 AM, Wu Zhe  wrote:
> Asynchronous daemon doesn't make much sense if page purge occurs on
> server side, but what if we put off page purge to the browser? It works
> like this:
>
> 1. mw parser send request to daemon
> 2. daemon finds the work non-trivial, reply *immediately* with a best
>   fit or just a place holder
> 3. browser renders the page, finds it's not final, so sends a request to
>   daemon directly using AJAX
> 4. daemon reply to the browser when thumbnail is ready
> 5. browser replace temporary best fit / place holder with new thumb
>   using Javascript
>
> Daemon now have to deal with two kinds of clients: mw servers and
> browsers.
>
> Letting browser wait instead of mw server has the benefit of reduced
> latency for users while still have an acceptable page to read before
> image replacing takes place and a perfect page after that. For most of
> users, it's likely that the replacing occurs as soon as page loading
> ends, since transfering page takes some time, and daemon would have
> already finished thumbnailing in the process.

How long does it take to thumbnail a typical image, though?  Even a
parser cache hit (but Squid miss) will take hundreds of milliseconds
to serve and hundreds of more milliseconds for network latency.  If
we're talking about each image adding 10 ms to the latency, then it's
not worth it to add all this fancy asynchronous stuff.

Moreover, in MediaWiki's case specifically, *very* few requests should
actually require the thumbnailing.  Only the first request for a given
size of a given image should ever require thumbnailing: that can then
be cached more or less forever.  So it's not a good case to optimize
for.  If the architecture should be simplified significantly at the
cost of slight extra latency in 0.01% of requests, I think it's clear
that the simpler architecture is superior.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Thomas Dalton]

2009/4/24 Chad :
> And the vast vast majority don't use preferences. I don't think it'll
> be a huge issue. The extensions that are broken and people use
> will quickly be found and fixed.

How gracefully will old extensions fail?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Trevor Parscal]

While from a user's perspective the various editors seen on the page you 
linked to appear to be drop-in replacements for the current plain text 
solution, I can assure you that there are many other reasons for not yet 
deploying them on Wikipedia that go far beyond our ability to provide 
users with a preference to turn them off. Almost all of those visual 
editors require the use of not-yet-stable reverse parsing, and many 
cause articles to change in ways the user did not intend, such as adding 
white-space places the user did not touch, or stripping out HTML 
comments from the code. There are other downsides as well, which are 
represented in an article closely related to the one you linked to, 
which is the results of the extensions chosen for evaluation from the 
list of nominated ones.

http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/Results

An existing example of us providing users with such an option however 
can be seen in the ability to turn various editing-related gadgets such 
as wikiEd. I think this shows that should a more visual editing 
interface become able to be deployed, we certainly would make it optional.

- Trevor Parscal

On 4/24/09 5:30 AM, Jacopo Corbetta wrote:
> On Fri, Apr 24, 2009 at 05:59, Andrew Garrett  wrote:
>
>> I'd like to look towards trimming some of the existing preferences
>> that are no longer relevant, and adding new preferences as common
>> sense dictates.
>>  
>
> Can I suggest adding a "preferred editor" preference?
> Ideally, it should be a dropdown box (given the variety of existing
> visual 
> editors,
> an admin might wish to install more than one), but a simple "disable
> the visual editor" checkbox is probably enough for most setups (and
> simpler to maintain).
>
> Thanks, bye
> --
> Jacopo Corbetta
> j.corbe...@sssup.it
> jacopo.corbe...@gmail.com
>
> WYMeditor MediaWiki integration:
> http://www.mediawiki.org/wiki/Extension:MeanEditor
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brion Vibber]

On 4/24/09 6:36 AM, Eugene Zelenko wrote:
> Hi!
>
> On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett  
> wrote:
>> The advantage of this clear separation is that writing an API module
>> is very simple, and it can be called internally, too!
>
> I think will be good idea to use API internally (not only have
> possibility to call), as result code will have more testing and
> coverage.

My general inclination is to structure code into a couple layers:

Backend/internal interface:
* Wraps over direct database, processing, etc

User interface:
* Web UI
* API module

Client-side JavaScript UI code can use the API to reach the backend, but 
I don't see much benefit to trying to use the API on the PHP UI end; 
it'll generally just be awkward.

API code should rarely have to do any serious DB or processing work 
itself; it should be calling the backend model/controller-level interface.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Roan Kattouw]

2009/4/24 Aryeh Gregor :
> How long does it take to thumbnail a typical image, though?  Even a
> parser cache hit (but Squid miss) will take hundreds of milliseconds
> to serve and hundreds of more milliseconds for network latency.  If
> we're talking about each image adding 10 ms to the latency, then it's
> not worth it to add all this fancy asynchronous stuff.
>
The problem here seems to be that thumbnail generation times vary a
lot, based on format and size of the original image. It could be 10 ms
for one image and 10 s for another, who knows.

> Moreover, in MediaWiki's case specifically, *very* few requests should
> actually require the thumbnailing.  Only the first request for a given
> size of a given image should ever require thumbnailing: that can then
> be cached more or less forever.
That's true, we're already doing that.

> So it's not a good case to optimize
> for.
AFAICT this isn't about optimization, it's about not bogging down the
Apache that has the misfortune of getting the first request to thumb a
huge image (but having a dedicated server for that instead), and about
not letting the associated user wait for ages. Even worse, requests
that thumb very large images could hit the 30s execution limit and
fail, which means those thumbs will never be generated but every user
requesting it will have a request last for 30s and time out.

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Chad]

All true. The images should not be rethumb'd unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged. However, on initial rendering,
the thumb generation can be a large part (especially if
rendering multiple images) of overall page execution time.
Being able to offload this elsewhere should decrease
that load greatly.

-Chad

On Apr 24, 2009 1:23 PM, "Roan Kattouw"  wrote:

2009/4/24 Aryeh Gregor

>:

> How long does it take to thumbnail a typical image, though?  Even a >
parser cache hit (but Squid ...
The problem here seems to be that thumbnail generation times vary a
lot, based on format and size of the original image. It could be 10 ms
for one image and 10 s for another, who knows.

> Moreover, in MediaWiki's case specifically, *very* few requests should >
actually require the thu...
That's true, we're already doing that.

> So it's not a good case to optimize > for.
AFAICT this isn't about optimization, it's about not bogging down the
Apache that has the misfortune of getting the first request to thumb a
huge image (but having a dedicated server for that instead), and about
not letting the associated user wait for ages. Even worse, requests
that thumb very large images could hit the 30s execution limit and
fail, which means those thumbs will never be generated but every user
requesting it will have a request last for 30s and time out.

Roan Kattouw (Catrope)

___ Wikitech-l mailing list
wikitec...@lists.wikimedia
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Roan Kattouw]

2009/4/24 Chad :
> All true. The images should not be rethumb'd unless
> resolution changes, a new version is uploaded, or the
> cache is otherwise purged.
Repeat: this is what we do already (not sure if that's what you're
trying to say, but "should" implies differently).

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 12:59 PM, Thomas Dalton  wrote:
> 2009/4/24 Chad :
>> And the vast vast majority don't use preferences. I don't think it'll
>> be a huge issue. The extensions that are broken and people use
>> will quickly be found and fixed.
>
> How gracefully will old extensions fail?

I'd assume fatally, but extensions sometimes break when core code
updates.  That's a fact of life.  One way to avoid this is to ask to
get it checked into Wikimedia SVN, so a grep can show that there are
users and they can be fixed by whoever makes the breaking change.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Andrew Garrett]

On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
 wrote:
> Hoi,
> How much work do you think it will be to repair an extension that needs
> repair ? For someone who knows the code and for someone who just has to
> repair his one extension ??

It's a reasonably simple fix. Here's an example: [1]

Essentially, all you need to do is remove your existing preferences
code, hook GetPreferences, and add your preference to the array. I'll
be posting documentation as to the format of preference entries
tomorrow, but for now you can look at the examples in
includes/Preferences.php.

[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690

-- 
Andrew Garrett
Sent from Sydney, Nsw, Australia

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Chad]

I'm agreeing with you. By "should" I meant "this should
be happening already and issues with this are bugs."

-Chad

On Apr 24, 2009 1:32 PM, "Roan Kattouw"  wrote:

2009/4/24 Chad :

> All true. The images should not be rethumb'd unless > resolution changes,
a new version is uploade...
Repeat: this is what we do already (not sure if that's what you're
trying to say, but "should" implies differently).

Roan Kattouw (Catrope) ___
Wikitech-l mailing list

Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Brion Vibber]

On 4/24/09 10:32 AM, Roan Kattouw wrote:
> 2009/4/24 Chad:
>> All true. The images should not be rethumb'd unless
>> resolution changes, a new version is uploaded, or the
>> cache is otherwise purged.
> Repeat: this is what we do already (not sure if that's what you're
> trying to say, but "should" implies differently).

Just to summarize the current state, here's the default MediaWiki 
configuration workflow:

* During page rendering, MediaWiki checks if a thumb of the proper size 
exists.
   * if not, we resize it synchronously on the same server (via GD or 
shell out to ImageMagick etc)
   * an  pointing to the file is added to output
* The web browser loads up the already-rendered image file in the page.


Here's the behavior variant we have on Wikimedia sites:

* During page rendering, we make an  pointing to where the 
thumbnail should be
* The web browser requests the thumbnail image file
   * If it doesn't exist, the upload web server proxies the request [1] 
back to MediaWiki, running on a subcluster which handles only thumbnail 
generation
 * MediaWiki resizes it synchronously via shell out to ImageMagick
   * The web server serves the now-completed file back to the client, 
and it's now on disk for the next request

[1] http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/upload-scripts/

This prevents slow or broken thumbnailing operations from bogging down 
the *main* web servers, but if it's not reasonably fast we still have 
difficulties:

* No placeholder image -- browser just shows a nice blank box
* Multiple requests will cause multiple attempts to resize at once, 
potentially eating up all CPU time/memory/tmp disk space on the 
thumbnailing cluster

So if we've got, say, a 50 megapixel PNG or TIFF high-res scan, or a 
giant animated GIF which is very expensive to resize, we don't have a 
good way of producing a thumbnail on a good schedule. It'll either time 
out a lot every time it changes, or just never actually complete.

If we have a way to defer things we know will take longer, and show a 
placeholder until it's completed, then we can use those things more 
reliably.


One suggestion that's been brought up for large images is to create a 
smaller version *once at upload time* which can then be used to quickly 
create inline thumbnails of various sizes on demand. But we still need 
some way to manage that asynchronous initial rendering, and have some 
kind of friendly behavior for what to show while it's working.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brion Vibber]

On 4/24/09 10:34 AM, Aryeh Gregor wrote:
> On Fri, Apr 24, 2009 at 12:59 PM, Thomas Dalton  
> wrote:
>> 2009/4/24 Chad:
>>> And the vast vast majority don't use preferences. I don't think it'll
>>> be a huge issue. The extensions that are broken and people use
>>> will quickly be found and fixed.
>> How gracefully will old extensions fail?
>
> I'd assume fatally, but extensions sometimes break when core code
> updates.  That's a fact of life.  One way to avoid this is to ask to
> get it checked into Wikimedia SVN, so a grep can show that there are
> users and they can be fixed by whoever makes the breaking change.

I believe they'll just not have their extended preferences displayed 
until they've updated to work with the non-crappy, actually sanely 
extensible, preferences interface.

Nothing else would be affected.

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Gerard Meijssen]

Hoi,
At the moment we have an upper limit of 100Mb. The people who do
restorations have one file that is 680Mb.. The corresponding jpg is also
quite big  !!
Thanks,
   GerardM

2009/4/24 Roan Kattouw 

> 2009/4/24 Aryeh Gregor 
> 
> >:
> > How long does it take to thumbnail a typical image, though?  Even a
> > parser cache hit (but Squid miss) will take hundreds of milliseconds
> > to serve and hundreds of more milliseconds for network latency.  If
> > we're talking about each image adding 10 ms to the latency, then it's
> > not worth it to add all this fancy asynchronous stuff.
> >
> The problem here seems to be that thumbnail generation times vary a
> lot, based on format and size of the original image. It could be 10 ms
> for one image and 10 s for another, who knows.
>
> > Moreover, in MediaWiki's case specifically, *very* few requests should
> > actually require the thumbnailing.  Only the first request for a given
> > size of a given image should ever require thumbnailing: that can then
> > be cached more or less forever.
> That's true, we're already doing that.
>
> > So it's not a good case to optimize
> > for.
> AFAICT this isn't about optimization, it's about not bogging down the
> Apache that has the misfortune of getting the first request to thumb a
> huge image (but having a dedicated server for that instead), and about
> not letting the associated user wait for ages. Even worse, requests
> that thumb very large images could hit the 30s execution limit and
> fail, which means those thumbs will never be generated but every user
> requesting it will have a request last for 30s and time out.
>
> Roan Kattouw (Catrope)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 1:22 PM, Roan Kattouw  wrote:
> The problem here seems to be that thumbnail generation times vary a
> lot, based on format and size of the original image. It could be 10 ms
> for one image and 10 s for another, who knows.

Is it really necessary for any image to take 10s to thumbnail?  I
guess this would only happen for very large images -- perhaps we could
make sure to cache an intermediate-sized thumbnail as soon as the
image is uploaded, and then scale that down synchronously on request,
which should be fast.  Similarly, if specific image features
(progressive JPEG or whatever) make images much slower to thumbnail,
an intermediate version can be automatically generated on upload
without those features.  Of course you'd see a little loss in quality
from the double operation, but it seems like a more robust solution
than trying to use JavaScript.

I'm not an expert on image formats, however, so maybe I'm
misunderstanding our options.

> AFAICT this isn't about optimization, it's about not bogging down the
> Apache that has the misfortune of getting the first request to thumb a
> huge image (but having a dedicated server for that instead), and about
> not letting the associated user wait for ages.

"Not letting the associated user wait for ages" is called "making it
faster", which I'd say qualifies as optimization.  :)

> Even worse, requests
> that thumb very large images could hit the 30s execution limit and
> fail, which means those thumbs will never be generated but every user
> requesting it will have a request last for 30s and time out.

max_execution_time applies only to the time that PHP actually spends
executing.  If it's sleeping on a network request, it will never be
killed for reaching the max execution time.  Try running this code:

ini_set( 'max_execution_time', 5 );
error_reporting( E_ALL | E_STRICT );
ini_set( 'display_errors', 1 );

file_get_contents(
'http://toolserver.org/~simetrical/tmp/delay.php?len=10' );

echo "Fetched long URL!";

while ( true );

It will fetch the URL (which takes ten seconds), then only die after
the while ( true ) runs for about five seconds.  The same goes for
long database queries, etc.  I imagine it uses the OS's reports on
user/system time used instead of real time.

Plus, the idea is apparently for this to not be done by the server at
all, but by the client, so there will be no latency for the overall
page request anyway.  The page will load immediately, only the images
will wait if there's any waiting to be done.

On Fri, Apr 24, 2009 at 1:46 PM, Brion Vibber  wrote:
> One suggestion that's been brought up for large images is to create a
> smaller version *once at upload time* which can then be used to quickly
> create inline thumbnails of various sizes on demand. But we still need
> some way to manage that asynchronous initial rendering, and have some
> kind of friendly behavior for what to show while it's working.

That's what occurred to me.  In that case, the only possible thing to
do seems to be to just have the image request wait until the image is
thumbnailed.  I guess you could show a placeholder image, but that's
probably *less* friendly to the user, as long as we've specified the
height and width in the HTML.  The browser should provide some kind of
placeholder already while the image is loading, after all, and if we
let the browser provide the placeholder, then at least the image will
appear automatically when it's done thumbnailing.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Michael Dale]

Roan Kattouw wrote:
> The problem here seems to be that thumbnail generation times vary a
> lot, based on format and size of the original image. It could be 10 ms
> for one image and 10 s for another, who knows.
>
>   
yea again if we only issue the big resize operation on initial upload 
with a memory friendly in-place library like vips I think we will be 
oky. Since the user just waited like 10-15 minutes to upload their huge 
image waiting an additional 10-30s at that point for thumbnail and 
"instant gratification" of seeing your image on the upload page ... is 
not such a big deal.  Then in-page use derivatives could predictably 
resize the 1024x786 ~or so~ image in realtime again instant 
gratification on page preview or page save.

Operationally this could go out to a thumbnail server or be done on the 
apaches if they are small operations it may be easier to keep the 
existing infrastructure than to intelligently handle the edge cases 
outlined. ( many resize request at once, placeholders, image proxy / 
deamon setup)

> AFAICT this isn't about optimization, it's about not bogging down the
> Apache that has the misfortune of getting the first request to thumb a
> huge image (but having a dedicated server for that instead), and about
> not letting the associated user wait for ages. Even worse, requests
> that thumb very large images could hit the 30s execution limit and
> fail, which means those thumbs will never be generated but every user
> requesting it will have a request last for 30s and time out.
>
>   

Again this may be related to the use of unpredictable memory usage of 
image-magic when resizing large images instead of a fast memory confined 
resize engine, no?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[David Gerard]

2009/4/24 Aryeh Gregor :

> That's what occurred to me.  In that case, the only possible thing to
> do seems to be to just have the image request wait until the image is
> thumbnailed.  I guess you could show a placeholder image, but that's
> probably *less* friendly to the user, as long as we've specified the
> height and width in the HTML.  The browser should provide some kind of
> placeholder already while the image is loading, after all, and if we
> let the browser provide the placeholder, then at least the image will
> appear automatically when it's done thumbnailing.


There was a spec in earlier versions of HTML to put a low-res
thumbnail up while the full image dribbled through your dialup -  - but it was so little
used (I know of no cases) that I don't know if it's even supported in
browsers any more.

http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Gerard Meijssen]

Hoi,
The library of Alexandria uses it for the display of their awesome
Napoleontic lithographs.. It would be awesome if we had that code.. It is
actually open source..
Thanks,
 Gerard

2009/4/24 David Gerard 

> 2009/4/24 Aryeh Gregor 
> 
> >:
>
> > That's what occurred to me.  In that case, the only possible thing to
> > do seems to be to just have the image request wait until the image is
> > thumbnailed.  I guess you could show a placeholder image, but that's
> > probably *less* friendly to the user, as long as we've specified the
> > height and width in the HTML.  The browser should provide some kind of
> > placeholder already while the image is loading, after all, and if we
> > let the browser provide the placeholder, then at least the image will
> > appear automatically when it's done thumbnailing.
>
>
> There was a spec in earlier versions of HTML to put a low-res
> thumbnail up while the full image dribbled through your dialup -  lowsrc="image-placeholder.gif" src="image.gif"> - but it was so little
> used (I know of no cases) that I don't know if it's even supported in
> browsers any more.
>
> http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html
>
>
> - d.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Brion Vibber]

On 4/24/09 11:05 AM, Michael Dale wrote:
> Roan Kattouw wrote:
>> The problem here seems to be that thumbnail generation times vary a
>> lot, based on format and size of the original image. It could be 10 ms
>> for one image and 10 s for another, who knows.
>>
>>
> yea again if we only issue the big resize operation on initial upload
> with a memory friendly in-place library like vips I think we will be
> oky. Since the user just waited like 10-15 minutes to upload their huge
> image waiting an additional 10-30s at that point for thumbnail and
> "instant gratification" of seeing your image on the upload page ... is
> not such a big deal.

Well, what about the 5 million other users browsing Special:Newimages? 
We don't want 50 simultaneous attempts to build that first 
über-thumbnail. :)

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[lists]

>> with a memory friendly in-place library like vips I think we will be
>> oky. Since the user just waited like 10-15 minutes to upload their huge
>> image waiting an additional 10-30s at that point for thumbnail and
>> "instant gratification" of seeing your image on the upload page ... is
>> not such a big deal.
>
> Well, what about the 5 million other users browsing Special:Newimages?
> We don't want 50 simultaneous attempts to build that first
> über-thumbnail. :)

Thumbnail generation could be cascaded, i.e. 120px thumbs could be
generated from the 800px previews instead of the original images.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 2:44 PM, Brion Vibber  wrote:
> Well, what about the 5 million other users browsing Special:Newimages?
> We don't want 50 simultaneous attempts to build that first
> über-thumbnail. :)

You'd presumably use some kind of locking to stop multiple workers
from trying to render thumbnails of the same size in general
(über-thumbnails or not).

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Brion Vibber]

On 4/24/09 12:07 PM, Aryeh Gregor wrote:
> On Fri, Apr 24, 2009 at 2:44 PM, Brion Vibber  wrote:
>> Well, what about the 5 million other users browsing Special:Newimages?
>> We don't want 50 simultaneous attempts to build that first
>> über-thumbnail. :)
>
> You'd presumably use some kind of locking to stop multiple workers
> from trying to render thumbnails of the same size in general
> (über-thumbnails or not).

Best to make it explicit rather than presume -- currently we have no 
such locking for slow resizing requests. :)

-- brion

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Jacopo Corbetta]

On Fri, Apr 24, 2009 at 19:04, Trevor Parscal  wrote:
> While from a user's perspective the various editors seen on the page you
> linked to appear to be drop-in replacements for the current plain text
> solution, I can assure you that there are many other reasons for not yet
> deploying them on Wikipedia that go far beyond our ability to provide
> users with a preference to turn them off.

Many wikis use MediaWiki beside Wikipedia.

> An existing example of us providing users with such an option however
> can be seen in the ability to turn various editing-related gadgets such
> as wikiEd. I think this shows that should a more visual editing
> interface become able to be deployed, we certainly would make it optional.

Exactly. Each editor has its own incompatible setting which allows it
to be turned on or off. Basically, each extension assumes it is going
to be the one and only one editor for the wiki. If you install more
than one, things will break. A unified preference might have been
useful. Anyway, no big deal.

Bye,
--
Jacopo Corbetta
j.corbe...@sssup.it
jacopo.corbe...@gmail.com

WYMeditor MediaWiki integration:
http://www.mediawiki.org/wiki/Extension:MeanEditor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 3:58 PM, Brion Vibber  wrote:
> Best to make it explicit rather than presume -- currently we have no
> such locking for slow resizing requests. :)

Yes, definitely.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Thomas Dalton]

2009/4/24 Jacopo Corbetta :
>> An existing example of us providing users with such an option however
>> can be seen in the ability to turn various editing-related gadgets such
>> as wikiEd. I think this shows that should a more visual editing
>> interface become able to be deployed, we certainly would make it optional.
>
> Exactly. Each editor has its own incompatible setting which allows it
> to be turned on or off. Basically, each extension assumes it is going
> to be the one and only one editor for the wiki. If you install more
> than one, things will break. A unified preference might have been
> useful. Anyway, no big deal.

I don't believe any WYSIWYG (or close to) editor that exists for
MediaWiki is good enough that you can completely avoid editing the
wikitext directly (in order to do complicated stuff), that means you
can't use one and only one editor unless that editor is the default
wikitext editor.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Alex]

Jacopo Corbetta wrote:
> On Fri, Apr 24, 2009 at 19:04, Trevor Parscal  wrote:
>> While from a user's perspective the various editors seen on the page you
>> linked to appear to be drop-in replacements for the current plain text
>> solution, I can assure you that there are many other reasons for not yet
>> deploying them on Wikipedia that go far beyond our ability to provide
>> users with a preference to turn them off.
> 
> Many wikis use MediaWiki beside Wikipedia.
> 
>> An existing example of us providing users with such an option however
>> can be seen in the ability to turn various editing-related gadgets such
>> as wikiEd. I think this shows that should a more visual editing
>> interface become able to be deployed, we certainly would make it optional.
> 
> Exactly. Each editor has its own incompatible setting which allows it
> to be turned on or off. Basically, each extension assumes it is going
> to be the one and only one editor for the wiki. If you install more
> than one, things will break. A unified preference might have been
> useful. Anyway, no big deal.

Extensions can add their own preferences more easily now. Adding a
default preference to turn off a feature that doesn't yet exist in
MediaWiki core doesn't make much sense.

-- 
Alex (wikipedia:en:User:Mr.Z-man)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Soxred93]

Keep in mind that when MediaWiki is developed, the best interests of  
Wikimedia are in mind. Wikimedia takes priority on MW development.


X!

On Apr 24, 2009, at 4:02 PM [Apr 24, 2009 ], Jacopo Corbetta wrote:


Many wikis use MediaWiki beside Wikipedia.




PGP.sig
Description: This is a digitally signed message part
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brian]

What does this have to do with not horribly breaking many extensions at the
same time? The WMF has cultivated an extension ecosystem and it makes sense
to protect it.

On Fri, Apr 24, 2009 at 2:23 PM, Soxred93  wrote:

> Keep in mind that when MediaWiki is developed, the best interests of
> Wikimedia are in mind. Wikimedia takes priority on MW development.
>
> X!
>
>
> On Apr 24, 2009, at 4:02 PM [Apr 24, 2009 ], Jacopo Corbetta wrote:
>
>  Many wikis use MediaWiki beside Wikipedia.
>>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Gerard Meijssen]

Hoi,
How much work do you think it will be to repair an extension that needs
repair ? For someone who knows the code and for someone who just has to
repair his one extension ??
Thanks,
  GerardM

2009/4/24 Brian 

> How many non-WMF extensions will this break?
>
> On Thu, Apr 23, 2009 at 9:59 PM, Andrew Garrett  >wrote:
>
> > I've branch-merged the new preferences system that I've spent the last
> > few weeks developing.
> >
> > On the outside, you probably won't notice any difference except a few
> > bugfixes, but the internals have undergone a complete rewrite.
> >
> > All of the actual preference definitions and utility functions have
> > been separated out into Preferences.php, which holds all business
> > logic for the new system. The UI and submission logic for the system
> > is done in SpecialPreferences.php, which, now only a hundred lines
> > long, wraps a generic class I've written to encourage separation of
> > business and UI logic called 'HTMLForm'.
> >
> > The advantage of this clear separation is that writing an API module
> > is very simple, and it can be called internally, too!
> >
> > Extensions must now hook GetPreferences instead of the existing hooks
> > (which were too low-level to maintain compatibility with), I've
> > updated all extensions used on Wikimedia. This new hook allows you to
> > put preferences wherever you want, and a new preference can be added
> > in less than ten lines of code, rather than the hundred-line nightmare
> > that was required in the previous iteration.
> >
> > I'd like to look towards trimming some of the existing preferences
> > that are no longer relevant, and adding new preferences as common
> > sense dictates.
> >
> > Feedback, praise and criticism regarding the changes is certainly
> welcome!
> >
> > --
> > Andrew Garrett
> > Sent from Sydney, Nsw, Australia
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brian]

I am just hoping to prevent a repeat of ParserPP.

On Fri, Apr 24, 2009 at 2:56 PM, Aryeh Gregor

> wrote:

> On Fri, Apr 24, 2009 at 4:23 PM, Soxred93  wrote:
> > Keep in mind that when MediaWiki is developed, the best interests of
> > Wikimedia are in mind. Wikimedia takes priority on MW development.
>
> Not as a general rule.  If we really didn't care about third-party
> users, we'd require the very latest version of PHP (since Wikimedia
> uses it), write large chunks of the software in other languages
> (Wikipedia has Python installed), and so on.  The suggestion to allow
> embedded Lua in templates seems not to be happening primarily because
> it would make Wikipedia content unusable by third parties on shared
> hosting.
>
> Although development of MediaWiki tends to focus primarily on
> Wikimedia's needs, it does *not* do so if that would significantly
> hurt MediaWiki's utility to third parties.  Part of Wikimedia's goals
> is to make its content as useful as possible to third parties.  That
> applies to MediaWiki insofar as it's a Wikimedia project, and doubly
> so insofar as it's needed to effectively use content from Wikimedia's
> other projects like Wikipedia.
>
> On Fri, Apr 24, 2009 at 4:25 PM, Brian  wrote:
> > What does this have to do with not horribly breaking many extensions at
> the
> > same time? The WMF has cultivated an extension ecosystem and it makes
> sense
> > to protect it.
>
> Do you have evidence that many extensions are, in fact, horribly
> broken?  And if so, that they can't be easily fixed?
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 4:23 PM, Soxred93  wrote:
> Keep in mind that when MediaWiki is developed, the best interests of
> Wikimedia are in mind. Wikimedia takes priority on MW development.

Not as a general rule.  If we really didn't care about third-party
users, we'd require the very latest version of PHP (since Wikimedia
uses it), write large chunks of the software in other languages
(Wikipedia has Python installed), and so on.  The suggestion to allow
embedded Lua in templates seems not to be happening primarily because
it would make Wikipedia content unusable by third parties on shared
hosting.

Although development of MediaWiki tends to focus primarily on
Wikimedia's needs, it does *not* do so if that would significantly
hurt MediaWiki's utility to third parties.  Part of Wikimedia's goals
is to make its content as useful as possible to third parties.  That
applies to MediaWiki insofar as it's a Wikimedia project, and doubly
so insofar as it's needed to effectively use content from Wikimedia's
other projects like Wikipedia.

On Fri, Apr 24, 2009 at 4:25 PM, Brian  wrote:
> What does this have to do with not horribly breaking many extensions at the
> same time? The WMF has cultivated an extension ecosystem and it makes sense
> to protect it.

Do you have evidence that many extensions are, in fact, horribly
broken?  And if so, that they can't be easily fixed?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Aryeh Gregor]

On Fri, Apr 24, 2009 at 4:59 PM, Brian  wrote:
> I am just hoping to prevent a repeat of ParserPP.

A *lot* more extensions use parser-related stuff than preferences.  In
any event, the upheaval of ParserPP was probably necessary given what
it sought to achieve.  That sort of thing happens from time to time --
it's not feasible for extensions with access to so many hooks and
methods to just work forever.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Platonides]

Michael Dale wrote:
> yea again if we only issue the big resize operation on initial upload 
> with a memory friendly in-place library like vips I think we will be 
> oky. Since the user just waited like 10-15 minutes to upload their huge 
> image waiting an additional 10-30s at that point for thumbnail and 
> "instant gratification" of seeing your image on the upload page ... is 
> not such a big deal.

It can be parallelized, starting rendering the thumb while the file
hasn't been completely uploaded yet (most formats will allow to do that).
That'd need special software, the easiest would be to use a different
domain on Special:Upload action to the resizing cluster. These changes
are always an annoyance but it would ease many bugs: 10976, 16751,
18202, upload bar, non-NFS backend...


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Platonides]

Alex wrote:
> Extensions can add their own preferences more easily now. Adding a
> default preference to turn off a feature that doesn't yet exist in
> MediaWiki core doesn't make much sense.

A preference name could be reserved to be consistently used by all
alternate editors.
Anyway, IMHO any alternate editor should offer an option to disable it
directly on the edit page, regardless of a preference which would define
"don't appear by default".



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Platonides]

Also relevant: 17255 and 18201
And as this would be a new upload ssytem, also worth mentioning 18563
(new-upload branch)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Google Summer of Code: accepted projects

[Brad Jorsch]

On Fri, Apr 24, 2009 at 07:08:05PM +0100, David Gerard wrote:
> 
> There was a spec in earlier versions of HTML to put a low-res
> thumbnail up while the full image dribbled through your dialup -  lowsrc="image-placeholder.gif" src="image.gif"> - but it was so little
> used (I know of no cases) that I don't know if it's even supported in
> browsers any more.
> 
> http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html

I tried it with FireFox 3.0.9 and IE 7.0.6001.18000; neither paid any
attention to it. IE 6.0.2800.1106 under Wine also ignored it. Too bad,
that would have been nice if it worked.

I don't know that we need fancy AJAX if we know at page rendering time
whether the image is available, though. We might be able to get away
with a simple script like this:
  var ImageCache={};
  function loadImage(id, url){
  var i = document.getElementById(id);
  if(i){
  var img = new Image();
  ImageCache[id] = img;
  img.onload=function(){ i.src = url; ImageCache[id]=null; };
  img.src = url;
  }
  }
And then generate the  tag with the placeholder and some id, and
call that function onload for it. Of course, if there are a lot of these
images on one page then we might run into the browser's concurrent
connection limit, which an AJAX solution might be able to overcome.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Brian]

Whatever happened to object-oriented programming and abstraction? Why can't
you define and provide a consistent API?

On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor

> wrote:

> On Fri, Apr 24, 2009 at 4:59 PM, Brian  wrote:
> > I am just hoping to prevent a repeat of ParserPP.
>
> A *lot* more extensions use parser-related stuff than preferences.  In
> any event, the upheaval of ParserPP was probably necessary given what
> it sought to achieve.  That sort of thing happens from time to time --
> it's not feasible for extensions with access to so many hooks and
> methods to just work forever.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Chad]

APIs change in incompatible ways sometimes. When it's avoidable, that's
great. Andrew seems to indicate that in this case, it wasn't possible to keep
the hooks identical to how they were. That's why its best to keep extensions
in svn so developers can easily spot and fix issues like this when they arise.

-Chad

On Fri, Apr 24, 2009 at 6:50 PM, Brian  wrote:
> Whatever happened to object-oriented programming and abstraction? Why can't
> you define and provide a consistent API?
>
> On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor
> 
>> wrote:
>
>> On Fri, Apr 24, 2009 at 4:59 PM, Brian  wrote:
>> > I am just hoping to prevent a repeat of ParserPP.
>>
>> A *lot* more extensions use parser-related stuff than preferences.  In
>> any event, the upheaval of ParserPP was probably necessary given what
>> it sought to achieve.  That sort of thing happens from time to time --
>> it's not feasible for extensions with access to so many hooks and
>> methods to just work forever.
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Alex]

Brian wrote:
> Whatever happened to object-oriented programming and abstraction? Why can't
> you define and provide a consistent API?
> 

The old preferences system didn't use anything like that, which is why
it needed to be totally rewritten. The old system was basically a
hardcoded form and extensions had to add preferences by appending to the
HTML.

While backwards compatibility is nice, if it stands in the way of
improving something that needs improvement, the improvement should take
priority.

-- 
Alex (wikipedia:en:User:Mr.Z-man)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Trevor Parscal]

On 4/24/09 4:38 PM, Alex wrote:
> While backwards compatibility is nice, if it stands in the way of
> improving something that needs improvement, the improvement should take
> priority
Indeed - even Microsoft eventually abandoned Windows 3.1 
compatibility... And more recently compatibility with all software in 
existence.

- Trevor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

[Andrew Garrett]

On Sat, Apr 25, 2009 at 3:08 AM, Brion Vibber  wrote:
> On 4/24/09 6:36 AM, Eugene Zelenko wrote:
>> On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett  
>> wrote:
>>> The advantage of this clear separation is that writing an API module
>>> is very simple, and it can be called internally, too!
>>
>> I think will be good idea to use API internally (not only have
>> possibility to call), as result code will have more testing and
>> coverage.

> Client-side JavaScript UI code can use the API to reach the backend, but
> I don't see much benefit to trying to use the API on the PHP UI end;
> it'll generally just be awkward.
>
> API code should rarely have to do any serious DB or processing work
> itself; it should be calling the backend model/controller-level interface.

I mean, of course, that the back-end business logic interface can be
called internally, not that the API can be called internally.

-- 
Andrew Garrett

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l