Re: [Wikitech-l] HTML templating systems & MediaWiki - is this summary right?

[Peter Kaminski]

Hi Sumana,

I think a key concept you might want to capture is "separation of 
concerns" -- a templating engine allows separation of presentation logic 
from business logic.  Often, the two are handled by different people 
with different skills, in service of separate goals.  So having the 
templating engine specialized for presentation logic is important.


The point isn't so much that the templates look like a document, as much 
as they can be written in a simplified language that's specialized for 
outputting documents.


Also, I don't know if these are useful in this context, but I wanted to 
point to two of the cutting-edge template engines from the PHP 
frameworks world, as representatives of modern PHP template thinking:


Fabien Potencier's Twig
http://twig.sensiolabs.org/

Laravel's Blade
http://laravel.com/docs/templates#blade-templating
http://culttt.com/2013/09/02/using-blade-laravel-4/

Neither of these, though, are oriented to dual JavaScript/PHP support, 
which I think is an interesting path to consider.


And last, two Wikipedia pages that might be relevant:

https://en.wikipedia.org/wiki/Web_template_system
https://en.wikipedia.org/wiki/Comparison_of_web_template_engines

Pete

On 3/18/14, 20:27 PM, Sumana Harihareswara wrote:


I'm trying to understand what our current situation is and what our
choices are around HTML templating systems and MediaWiki, so I'm gonna
note what I think I understand so far in this mail and then would love
for people to correct me. TL;DR - did we already consense on a
templating system and I just missed it?

Description: An HTML templates system (also known as a templating
engine) lets you (the programmer) write something that looks more like a
document than it looks like code, then has hooks/entry points/macro
substitution points (for user input and whatnot) that then invoke code,
then emits finished HTML for the browser to render.

Examples: PHP itself is kinda a templating language. In the PHP world,
Smarty is a somewhat more mature/old-school choice. Mustache.js is a
popular modern choice. And in other languages, you'd pick a lot of the
MVC frameworks that are popular, e.g. Django or Jinja in Python.

Spectrum of approaches: One approach treats HTML as a string ("here's a
bunch of bytes to interpolate"). From a security perspective, this is
dangerously easy to have vulnerabilities in, because you just naively
insert strings. Then on the other end of the spectrum, you have code
that always keeps the document object model (DOM) in memory, so the
programmer is abstractly manipulating that data model and passing around
an object. Sure, it spits out HTML in the end, but inherent in the
method for turning those objects into HTML is a sanitization step, so
that's inherently more secure. There's some discussion at
https://www.mediawiki.org/wiki/Parsoid/Round-trip_testing/Templates . I
presume we want the latter, but that the former model is more performant?

We talked about this stuff in
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-21
and
https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/HTML_templating#Wrap_up:_Next_steps
. Based on that plus
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
it seems like we are supposed to get consensus on which system(s) to
use, and we kind of have four things we could choose:

* oojs - https://www.mediawiki.org/wiki/OOjs_UI -- could use this
toolkit with one of the template approaches below, or maybe this is
enough by itself! Currently used inside VisualEditor and I am not sure
whether any other MediaWiki extensions or teams are using it? This is a
DOM-based templating system.

Template approaches which are competing?:
* MVC framework - Wikia has written their own templating library that
Wikia uses (Nirvana). Owen Davis is talking about this tomorrow in the
RFC review meeting.
https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework
* mustache.js stuff - Ryan Kaldari and Chris Steipp mentioned this I think?
* Knockout-compatible implementation in Node.js & PHP
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/KnockoutProposal#Longer-term_architecture
and
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly
, being worked on by Gabriel Wicke, Matt Walker, and others. DOM-based.

There's also an OutputPage refactor suggested in
https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor
that's part of the HTML Templating RFC Cluster
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters#HTML_templating
.

I guess my biggest question right now is whether I have all the big
moving parts right in my summary above. Thanks.




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

Re: [Wikitech-l] .wiki gTLD

[Peter Kaminski]

Without getting into the value discussion, I wanted to note there's an 
official meta-registry called the Trademark Clearinghouse, in which 
owners of registered trademarks can block/reserve (as opposed to 
register) their marks in all the new gTLDs, so they don't get squatted.  
The protection fee at TMCH costs around $150/year/mark:


http://trademark-clearinghouse.com/content/trademark-clearinghouse-fees

I have an IP lawyer friend helping people with this new gTLD stuff if 
Wikimedia needs advice or help getting registered with the TMCH.


Pete

On 2/21/14, 13:22 PM, Chad wrote:


On Fri, Feb 21, 2014 at 1:19 PM, Paul Dugas wrote:


I believe there is a period of time before these TLDs go live when
trademark holders are supposed to register and that they want to acquire.
  Wonder if that means they loose the rights when that period ends.  Suspect
not.



Herein lies the probem: supposed to register. See Brion's earlier
comment about this all being an awful scam.

-Chad
___
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] [GSoC] tools for micromanagement

[Peter Kaminski]

On 5/10/13 04:16 AM, Antoine Musso wrote:

A bunch of people at Wikimedia uses https://trello.com/ . It let you 
define pipelines and stick cards in them which you can then drag'n drop.


It allows you to do this collaboratively with other people, too.  I 
recommend regular, short, synchronous checkins to go over your board(s) 
and move cards, along with the other people you're working with.  (Like 
a daily standup, but can be at longer intervals, depending on your project.)


I find this hugely productive for all kinds of projects, and recommend 
Trello (and checkins) highly.


Pete


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

[Wikitech-l] 40 million links to Wikipedia

[Peter Kaminski]

Here's big data dataset from Google Research and UMass IESL, 40 million 
"links to Wikipedia pages where the anchor text of the link closely 
matches the title of the target Wikipedia page," from 10 million web 
pages, for the purposes of contextualized disambiguation:


Learning from Big Data: 40 Million Entities in Context
http://googleresearch.blogspot.co.uk/2013/03/learning-from-big-data-40-million.html

In hopes that the work might be interesting or useful to the folks here,

Pete


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

Re: [Wikitech-l] Making the Lua/Javascript decision (Re: Performance roadmap update)

[Peter Kaminski]

On 12/21/11 11:18 AM, Owen Davis wrote:

> I'm going to look at something simple like Moustache (which has both
> JS and Lua implementations already) as a proof of concept.

I really like the idea of using JavaScript+Mustache+Node.js.  Plus
there's a Mustache compiler for Node:
, which should give us a little
performance boost.

I don't have anything particular against Lua and no particular love for
JavaScript, but JS seems more web-native; plus code and skills developed
can accrue to both client- and server-side of the web.

Pete
(in crunch mode at work, so no time to code up proofs-of-concept; mea culpa)


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

Re: [Wikitech-l] Html dump for Wikipedia

[Peter Kaminski]

Hi Khalida,

In a previous message, you mentioned that the speed of your Internet
connection and the storage capacity of your computer were giving you
trouble.

I know this is not directly on-topic on this list, but since you seem to
have tried and exhausted many options already, perhaps you would
consider running your code on a cloud-based computer, such as a server
from Amazon EC2?  Doing so would allow you to get around both connection
and storage issues, and perhaps allow you to run your Java code
successfully, or perhaps to run JWPL successfully.

Using EC2 is not particularly simple, but it is technically
straightforward and not too hard, either.  The Getting Started Guide is
here:

http://docs.amazonwebservices.com/AWSEC2/latest/GettingStartedGuide/

The pricing is quite inexpensive if you limit the number of hours you
use the servers.  There is even a free tier for new users
, although with your needs you might choose
to pay (again, a small amount) for server(s) with larger capacity.

I can offer a small bit of EC2 guidance off-list if you need other
pointers in getting started.

Pete

On 12/2/11 14:03 PM, Khalida BEN SIDI AHMED wrote:

> I need an Html dump of Wikipedia because I have written a java code which
> extract text from an html content and I would like to apply it on this
> dump. In fact I need to extract the first sentence of a list of articles
> (<200) and I don' know how to do it on other dumps. If you have any idea of
> other solutions, I will be pleased if you share them with me.
>


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

Re: [Wikitech-l] Wikipedia Android app – "Support Wikipedia" version

[Peter Kaminski]

It would be really cool to be able to donate via in-app billing.

Pete

On 10/7/11 14:35 PM, church.of.emacs.ml wrote:

> So I think we'll have to stick to fixed donation amounts. If someone
really wants to contribute a different amount, he can just use at
donate.wikimedia.org :)

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

Re: [Wikitech-l] Google tech talk last week

[Peter Kaminski]

On 9/12/11 09:54 AM, Erik Moeller wrote:

> http://www.youtube.com/watch?v=-6eHyShpws8 

Thanks, Erik, Rob, Alolita-- lots of geeky info, just like a tech talk
should be. :-)

The video ends abruptly before you're done with the presentation  -- is
that fixable, do you think?

Pete


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

Re: [Wikitech-l] Please don't commit broken code

[Peter Kaminski]

Great reminder, Brion.

Do any devs have suggestions of what to do instead of checking in broken
code?  Or even code you're not sure about?  Tips, reminders, places/ways
to ask for help?

Pete

On 7/28/11 14:49 PM, Brion Vibber wrote:

> Please don't commit broken code to trunk; if you think your code may be
> broken please consider asking about it first. This is especially true if
> you're committing a fix for a bug that's gone back and forth over the years
> about how it should be solved.
>
> And it's even more true if the particular thing you're committing has been
> previously committed and reverted several times due to ongoing issues.
>
> Folks that have a history of having commits reverted for problems -- please
> start considering this. It's easier to fix your code before it goes in than
> after.
>
> -- brion vibber (brion @ wikimedia.org)
>


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

Re: [Wikitech-l] Archival for Web Citations (GSoC project)

[Peter Kaminski]

Wikiwix, I think --

http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Archived_citations
http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_External_links/Webcitebot2

Kevin, you should check out the second link above for projects which are
potentially similar to yours.

Pete

On 6/1/11 13:59 PM, Thomas Morton wrote:

> You might want to dig into French Wikipedia. IIRC They run a link
> archival service (there was discussion about enabling it for English
> Wikipedia, but I don't think it came to anything) and might have some
> helpful material.
>
> I forget the name I'm afraid, it's discussed somewhere on the en.wiki
> Village Pump so I'll see if I can dig it out.
>
> Tom Morton


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

Re: [Wikitech-l] Community vs. centralized development

[Peter Kaminski]

  Aryeh Gregor writes,

> I'm not assuming that -- I've been idling in the secret channel for a 
> while now. (I keep almost saying its name, argh. Channels that aren't 
> access-restricted and rely on secret names are annoying.) Most of it 
> is just chitchat. But that's exactly something that the broader 
> community should be part of, so that staff doesn't form its own group 
> that excludes volunteers.

As a student of human communication, I'd like to affirm what Aryeh 
says.  Chit-chat is phatic communication -- part of group-forming and 
the way that people form social ties and learn how to work together.

Saying "we chit-chat over here" and "discuss development over there" 
imagines a false dichotomy between the two kinds of conversations, and 
draws a line between the two groups.  It ought to be "we chit-chat and 
discuss development together."

Pete


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

Re: [Wikitech-l] Wikigalore

[Peter Kaminski]

Gerard Meijssen writes,

> As far as leeches go, this takes the price as far as I am concerned. It
> sells scripts to leech any Wikimedia project and all this to have the rating
> of a website go up.
>   

The best long-term solution would be to work with Google and other 
search engines to encourage them to efficiently recognize Wikimedia 
content and reduce rankings of sites mirroring it just for SEO.

It wouldn't make much sense to leech Wikimedia if it adversely affected 
site rankings.

Pete


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

Re: [Wikitech-l] confirm dfe03c58a0a....

[Peter Kaminski]

Tim Starling writes,

> https://bugs.launchpad.net/mailman/+filebug

Thanks, Tim.

After a quick look at the bug tracker and other docs, I can say the 
issue had been reported long ago (at least a decade), and was on its way 
to getting fixed a couple of years ago in Mailman 2.2. However, I'm not 
sure that 2.2 ever made it out. (Wikitech-l is currently running on 
Mailman 2.1.9; the latest release looks to be 2.1.13.)

The good news: the problem has been fixed in Mailman 3.0: "Get rid of 
password reminders altogether. Encrypt member passwords and use a 
password reset feature instead of a reminder. (Done)"

The bad news: Mailman 3.0 is in alpha release right now -- probably not 
ready to use yet. Though it is currently under active development, so 
maybe sometime relatively soon.

References:

Bug #266390 in GNU Mailman: “Storing of passwords”
https://bugs.launchpad.net/mailman/+bug/266390

SourceForge.net: Mailman: Detail: 209499 - Security hole: passwords 
mailed in clear
http://sourceforge.net/tracker/index.php?func=detail&aid=209499&group_id=103&atid=100103

Milestones : GNU Mailman
https://launchpad.net/mailman/+milestones

Mailman 3.0 - Development - Confluence
http://wiki.list.org/display/DEV/Mailman+3.0

Pete


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

Re: [Wikitech-l] confirm dfe03c58a0a....

[Peter Kaminski]

Conrad Irwin writes,

> The point of the password is so you can prove to the web interface 
> that you own the email address; so the fact that it is in your email 
> box doesn't matter much. (If your email gets hacked this is the last 
> thing you're likely to be worried about after all.) As it says on sign 
> up "do not use a valuable password".

The problem with a cleartext password in email isn't that your email 
might get hacked.  It's that each device with access to the network path 
from list server to mail server and mail server to email client has 
access to the password.  Search the net for "password sniffer" for more 
information.

> In which case so could the password reset emails. It gains you nothing.

Password reset tokens or URLs are generally designed to be used one 
time, and then they expire.  The user generally uses it within a few 
minutes of initiating the password reset, preventing any later use of it.

On the other hand, sending a user's password through the mail exposes it 
to being logged for later use.  For a security-conscious user, it 
effectively spoils its use forever.

I agree that you shouldn't use a valuable password with Mailman, and 
that the Mailman project is the right place to ask for a change in 
Mailman's behavior.

Pete


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

Re: [Wikitech-l] Lightweight Wiki?

[Peter Kaminski]

Oddmuse  is a good candidate.  It's Perl+flat 
file, reasonably simple to use and maintain.

Depending on your needs, you might also consider TiddlyWiki 
, which is implemented entirely in 
client-side JavaScript, stored in a single HTML file which includes the 
script and the data.  There are many add-ons and customizations for it, 
and there are ways to save it to the local filesystem and/or a "ServerSide".

Probably unsuitable, but including it for completeness' sake: Sig Wik 
, which is implemented in 222 characters 
of Perl.

Pete

Dawson wrote:
> Can anyone recommend a really lightweight Wiki? Preferably PHP but flat file
> would be considered too.
>   

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