[00:00:06] gadget is not possible because it can't do this stuff [00:00:13] What kind of stuff are we talking about [00:00:14] how you connect to irc using a gadget? [00:00:20] or multiple wikis at once [00:00:20] you don't need to [00:00:43] ok how you parse the recent changes in real time, without using irc? [00:01:21] also is it possible to make a request queue? [00:01:35] easy, one thing at a time. [00:01:40] huggle is threaded [00:01:42] ok [00:01:46] let's start with irc [00:01:49] no [00:02:26] so as you might have heard. IRC sucks for data transmission. It's 1 string, anything but machine readable friendly and almost no wiki has it (other than wmf and wikia). [00:02:34] On the short term: API polling gives you JSON packages or XML [00:02:45] but it's slow [00:02:48] I know [00:02:54] there's more [00:02:58] only reason why people use huggle is a speed [00:03:14] * Krinkle is not confinced [00:03:35] https://www.mediawiki.org/wiki/Requests_for_comment/Structured_data_push_notification_support_for_recent_changes [00:03:53] You subscribe to one or more channels in that, and you've got the best of IRC and the API combined [00:03:56] and it works from the web [00:04:00] (client side) [00:04:01] who guarantee us that if we make an extension it will be deployed? [00:04:16] I could, but one other thing [00:04:17] I don't want to spend year programming something what is never going to be used [00:04:27] You say a gadget is not an option because one can't connect to IRC from javascript [00:04:29] that's truye [00:04:34] but how are you going to do it in the WA [00:04:48] people don't run user Huggle from the PHP shell right? [00:04:48] we have apache server and we can do whatever we want... so it's not problem [00:04:53] they are going to get HTML/JS/CSS in the browser [00:05:07] same issue, can't connect to IRC from the browser [00:05:16] it's even possible I create a background daemon to parse irc and create local cache in fs [00:05:22] php just parse it from there [00:05:42] no, server would be connected to irc [00:05:47] obviously [00:05:49] no need to use browser for that [00:05:54] so how is it going to get in the browser in real-time? [00:06:30] php ajax html5 java maybe e.t.c [00:06:32] I suppose that everytime user make an action it would need to reload the page, so they would get fresh rc after any action [00:06:42] or that [00:06:50] Exactly, you're going to use front-end technology to communicate to a server that parses it [00:06:51] the way I see it it is very simple [00:07:03] and that's exactly what can be done from anywhere, including a gadget [00:07:07] the simplest version possible would be to do this [00:07:20] server connects to irc and does what bhuggle currently does [00:07:23] so all you need to host elsewhere is the irc-proxy-ajax [00:07:34] check each edit and decide where in a list of edites to check it should be put [00:07:51] user logs into the web aplication [00:07:57] loads a page with the dif on, and buttons [00:08:08] click button, on clicking buttons actions happen and the next diff is loaded [00:08:15] e.t.c [00:08:30] each edit could be put in a DB to show what users reviewed the edit e.t.c [00:08:36] api to make edits and rollbacks [00:08:45] done [00:08:51] By building it in mediawiki (or on top of mediawiki) you can for example do an ajax request for rollback via the API (user is logged in, POST requests to the API are allowed) [00:08:53] then from there make it look nice and add mroe features [00:09:05] Krinkle, it will use the api [00:09:13] but you can't do rollbacks from another domain [00:09:15] it will use the api to get post login logout rollback [00:09:32] I see now reason why they would need to be [00:09:38] the rollback can be done from the users machine [00:09:50] Nope [00:10:05] ? [00:10:10] That would be a security whole, if I can build a website, point you to it and you'd be doing rollbacks without knowing [00:10:28] nah [00:10:33] rollbacks require login, and login only works via AJAX when request origin is the same domain [00:10:33] web server can act as huggle does [00:10:47] and asking user credentials is not allowed [00:10:55] who said that? [00:11:02] huggle already ask user for credentials [00:11:02] Krinkle you can request from the api to see if a user is logged in [00:11:12] yes, but now Huggle runs on the local machine [00:11:22] what is difference [00:11:33] server is going to be managed by huggle devs [00:11:37] addshore: no you can't. if you make an request from the browser to the API from another domain, the API treats you as an anonymous user [00:11:43] also i could point you to huggle currently and you could be doing rollbacks without you knowing [00:11:50] and huggle devs could already implement password logged to huggle if we wanted [00:11:55] * logger [00:12:01] it's not going to be less secure [00:12:03] petan: Sure, but that's the user's rusk [00:12:04] risk* [00:12:12] By installing the application [00:12:16] using browser version could be same risk [00:12:19] same risk will apply to the web appolication? [00:12:30] maybe, but it would be stored on a wikimedia server [00:12:38] however I believe oauth will be installed sooner than such an extenion would be [00:12:42] I don't think the policy allows that, neither does Toolserver. [00:12:48] however [00:13:00] but even if it would allow that, just for the sake of argument. Why would you want to do that, if you can just as easily do it from the same domain for real [00:13:01] I had the idea with extension too, and I like it [00:13:24] as a gadget. Basically anything you do in HTML/CSS can be done as a gadget. And the ajax requests can go from the gadget on-wiki to wmflabs to get the data [00:13:34] but then I was thinking of all the pain which comes with that, when community person like me, try to change something what needs to be done by wmf [00:13:35] so the logic would be on wmflabs, and the UI in a gadget on wikipedia [00:13:43] it's almost impossible from my experience [00:13:44] (not an extension) [00:14:18] this process is completely broken, I am not the only person who say it [00:14:41] you can't just come and say, guys I made a cool extension, install it to wikipedia, and boom it's done [00:14:56] it need to pass community (almost impossible) [00:15:06] it needs to pass the wmf devs (even harder) [00:15:09] Sure, I've heard that. and that's unfortunate, but I can't change that. And I agree. [00:15:14] So what about a gadget [00:15:34] I would never start working on extension if it wasn't already approved by either wmf and community [00:15:35] it's perfectly fine to have the proxy and the logic on labs. [00:16:03] gadget has too many limitations for us... I guess [00:16:05] then the UI on wikipedia, using the API from within the browser. (much faster as well, instead of going to server and server goes to wikipedia and then back again) [00:16:14] it would be nice to make a gadget as third option [00:16:19] petan: The logic isn't going in the gadget [00:16:21] like very "lite-huggle" [00:16:22] the logic is on the server [00:16:34] twinkle is gadget [00:16:40] the only thing in the gadget would be what you're planning to put in the HTML/CSS/JS [00:16:44] I don't believe we can make anything better than twinkle in gadget [00:16:46] the PHP can stay on labs [00:16:52] Yes you can [00:17:26] you know how hg work? [00:18:00] it's multithreaded, it parses the feed in one thread, load content of diffs in another thread, and display content in another... how this could be done using java script? [00:18:42] even if it was possible to somehow put the functionality of huggle to gadget, it would be extremely slow, and some functions could be never implemented there [00:19:20] I don't know how Huggle works, but I don't have to. I know for a fact that anything you can do from a web app that you plan to do on labs, can be done as a gadget. The only difference is this: [00:19:52] instead of having PHP output initial HTML and have javascript do requests to the server, you'd have the gadget build the HTML and make ajax requests to wmflabs [00:19:53] s [00:21:37] eh [00:21:41] I don't get it [00:21:53] you mean there would be a gadget which someone interact with labs? [00:21:58] Sure [00:22:00] * somehow [00:22:13] Exactly [00:22:32] ok describe it step by step [00:23:06] there is mediawiki which can't be touched much, it's managed by wmf, then there is webserver we can control... what is where [00:23:24] gadget on mediawiki... does what? [00:24:04] So, so just to make sure I understand what you are planning with Huggle WA, and then I'll map it to what I have in mind [00:24:37] User goes to huggle.wmflabs.org (or another domain that points to the same public IP); User logs in with their wiki credentials and hits "Go". [00:24:44] Server gets request does it's thing and outputs the UI [00:24:55] then javascript goes and gets information real-time [00:25:14] user can get diffs, do stuff. those go as request to the labs server, which then uses the user login and makes that request through the API [00:25:15] I don't know if it's going to work like this [00:25:15] etc. [00:25:18] we want to use sql db too [00:25:21] sure [00:25:26] but this is the general idea, right? [00:25:46] I think it would be best if we created a session for each user who is logged in, maybe even using oauth in future, where would be oauth token only [00:26:05] web application should work totally same as huggle [00:26:10] using same api's etc [00:26:17] yes, but then wmf needs to have oath first. but the login is a minor part of the app [00:27:01] it download user configuration, set up layout based on that, then it show the queue of diffs, and when someone click on diff, it dowloads it using api, and show [00:27:29] I believe oauth is going to be deployed sooner than such extension would be [00:27:50] so to map that concept to what I have in mind: user is logged into en.wikipedia.org and has a preference enabled. They go to Special:Huggle (or whatever) and the gadget detects that and builds the html framework. Then it makes an ajax request to huggle.wmflabs.org requesting the latest stuff. And goes on exactly like you would otherwise. [00:28:10] in fact there is idea to login to many project at once [00:28:17] so you get a feed of multiple wikis [00:28:23] it's for crosswiki spam etc [00:28:26] no problem [00:29:15] there is one [00:29:57] getting the queue for multiple wikis is a challenge, but that's not related to the gadget. that's related to the PHP backend. The front-end doesn't have to be external and not doing so would most definitely save a lot of bandwidth and development time. [00:30:05] I am a c# programmer like addshore I know some php basics, but nothing about html or javascript, Iworld who came with this, knows css html and php, maybe little bit javascript. If we move this to javascript only, in gadget, who is going to create it? [00:30:09] I'd be willing to help as a CVN developer. [00:30:31] ok, but you would be likely only dev who could work on that [00:30:32] and am an expert in front-end development and know a fair bit of PHP. No C# [00:30:44] petan i know c# vb.net php java html css sql [00:30:55] java or javascript? [00:31:03] both ;p [00:31:03] because we are talking about gadget only [00:31:05] ok [00:31:11] well, you're gonna need front-end developers for Huggle WA either way. Wether the UI is on labs or as gadget is a really minor difference. [00:31:11] then adam help you too [00:31:18] ewww gadget [00:31:19] xD [00:31:56] Either way, most of the logic will be on Labs in PHP. [00:31:57] Krinkle: I think you should find out wheter it's possible using gadget, maybe community just say: remove it from our wiki [00:32:10] That's the great thing about javascript [00:32:11] gadget is little bit like extenion [00:32:14] * extension [00:32:16] No it's not [00:32:17] not at all [00:32:26] It doesn't have to be hosted on wikipedia.org [00:32:31] at some point, people could complain because it's directly in wiki [00:32:39] the gadget file could be on labs and users just put importScriptURI in their mono book.js [00:33:09] that makes it slightly harder to install than the original idea, but ok [00:33:37] some people have no idea what monobook.js is [00:33:43] but I think it's still ok [00:34:06] The only advantage to having the gadget .js on wikipedia instead of elsewhere is that users can very easily enable it from the preferences [00:34:16] that would be better [00:34:42] if you're assuming the sysops don't trust Huggle, then why most certainly will not allow the gadget, neither the extension, nor will they ask for the wiki to be added by a Steward to the Huggle set [00:34:55] the assumption that the gadget is allowed should be default, otherwise there's no point. [00:35:16] however again, I can't help here, only thing I know about java script is that it sounds like a motocycle... so you should either check if it's really possible and if yes, convince Adam and IWorld to switch to that [00:36:00] I can help with various c++ daemons runnig in background, caching stuff etc [00:36:23] but javascript and layout goes beyond my knowledge [00:36:40] I can help to manage the instances on labs... [00:37:24] I know that it's possible because I've build various gadgets like it in the past [00:37:36] it used interaction to toolserver.org instead of labs though, but that's fine. [00:37:48] addshore what you think [00:37:59] sorry iv missed most of this [00:38:07] trying to deal with an on wiki article atm [00:38:14] delete it [00:38:19] ?Action=delete [00:39:04] damn almost 2 am [00:39:19] haha [00:39:25] quick question for you [00:39:29] right this article is about the film [00:39:33] not the movement [00:39:34] so the opening [00:39:35] Kony 2012 is a campaign started by Invisible Children Inc and the subject of an eponymous viral video.[2][3][4] The movement's purpose is to make Joseph Kony, a Ugandan war criminal, known to the world, for his successful arrest within the year 2012.[5] [00:39:39] is shit? :) [00:39:44] yes [00:39:54] care to re word it for me? :P [00:40:18] oh it's written by you? I think it's well written then [00:40:26] no, not written by me [00:40:29] :D [00:40:30] ok [00:40:47] Krinkle: you should start a talk on wikitech related to this [00:41:13] maybe we could find more devs who could help [00:42:26] ponymous viral video.[2][3][4] 3 references for viral video :D [00:42:35] xD [00:43:52] http://etherpad.wikimedia.org/WorT2b8qpR [00:43:55] Krinkle: in fact it's a good idea, but I am afraid lot of community would be against it [00:43:56] Very rough sketch [00:44:05] petan: Why would the community be against it? [00:44:11] it's a difference between installing stuff to your pc, and installing it to wiki itself [00:44:15] for them [00:44:17] I mean [00:44:25] some people on wikipedia are weird [00:44:26] It would be a lot less work [00:44:48] yes [00:44:55] for the user [00:44:58] I know [00:45:02] for user who wants to use it [00:45:20] but user who doesn't like huggle and use wikipedia would likely be against touching it [00:45:39] I know what some people think about huggle on wiki [00:45:50] why does it bother you that a user who doesn't like Huggle isn't going to touch it? [00:46:03] I mean touch wiki, not huggle [00:46:17] if there would be anything what needs to be approved by community, we fail [00:46:34] It makes no difference wether a user is going to install an application and do whatever Huggle offers him, or install a gadget and do the same. [00:46:41] yes I know [00:46:47] but regular people see it different [00:46:51] The end result in what's visible on-wiki is the same [00:47:04] did you check my extension for online status [00:47:20] and the great thing (also where most cross-site secure breaches originate from btw), is that it doesn't require anyones consensus [00:47:22] I created it because people were changing their userpages everytime when they logged in [00:47:26] it sucked [00:47:54] people were already doing it, no difference, it would be either done using extension, or by editing a page [00:48:12] but lot of people were against it, just because my way, was changing the code of wikipedia [00:48:49] Users can put this line into their common.js just to try it out. Or you could even make a preload template and point them to Special:Mypage/common.js?action=edit§ion=new&preload=Wikipedia:Huggle/load_gadget.js&editnotice=Wikipedia:Huggle/load_gadget_editnotice (which says "Just click save") [00:49:17] petan: Even the whoisonline extension could be entirely done as a gadget, saving to a wiki user page [00:49:18] via the API [00:49:38] but I created the extension to avoid touching the content pages [00:49:45] yes, because that's nicer [00:49:46] I agree [00:49:52] but as a proof of concept, it's nice [00:49:55] anyway, off-topic [00:50:12] I was trying to point to that, people are against changing anything on wikipedia [00:50:15] any change is bad [00:50:21] wikipedians are conservative [00:50:38] that isn't relevant to the Huggle gadget stuff [00:50:53] it's not a change for anyone who does not specifically enable it [00:51:11] that was same with my extension, and still people didn't like it [00:51:42] Then it might have been presented wrongly, I don't know but that's another story and this isn't an extension [00:51:55] maybe you are right but I think we should make a wider research before we start something big what fail because of something stupid [00:52:26] what kind of research ? [00:52:30] I create gadgets every week [00:52:36] at least we could start a talk on wikitech, maybe someone point us on some problem [00:52:45] ok [00:53:09] if u are sure it's going to work, you can of course make it, I am happy to help you, but I don't know if I can [00:53:23] because I don't know java script a bit [00:53:34] well I know for sure I am not going to have time or ability to create a php-framework to do whatever Huggle app does [00:53:59] But anything specific to the gadget I can help with [00:54:14] ok but how is gadget going to use the php framework? [00:54:21] and as you may or may or not realize at this point, wouldn't make a difference for the backend implementation. [00:54:24] to get the feed? [00:54:34] javascript = javascript [00:54:42] gadget = load a bunch of javascript and css [00:55:03] whatever method you're going to use to get the feed in the browser window on huggle.wmflabs.org can be used in a gadget [00:55:15] hm, ok [00:55:59] I think the performance at least could be problem because gadget can't work with threads, while I was told that php can do it [00:56:14] php doesn't run in the browser [00:56:29] I was thinking of putting requests to queue instead of running them straight [00:56:33] gadget (javascript) is not the mirror part of php, it's the mirror part of html [00:56:46] so that someone could rollback diff and load another one in parallel [00:56:49] you can use threads all you like on the server [00:56:51] etc [00:57:14] if you know a way to do multi-thread stuff on huggle.wmflabs.org in the browser then you can do it in a gadget as well [00:57:18] however neither is possible [00:57:32] no I was thinking of doing it on server [00:57:48] then the problem is solved [00:57:59] ok let's give it a try, I need to sleep [00:58:10] late in eu [00:58:11] I'll write to wikitech :) [00:58:13] ok [00:58:20] I'm on a nightshift [00:58:26] addshore: ?action=delete ;) [00:58:33] fix it! [00:58:34] awake from 5PM to 7AM [00:58:38] hm... [00:59:16] haha [00:59:23] but you go sleep after that. I have to wake up at 7am [00:59:31] :) [00:59:45] what timezone are you in? [00:59:49] gmt+1 [00:59:54] 2 am [00:59:54] me too [01:00:02] France? [01:00:05] Germany? [01:00:08] czech [01:00:10] ok [01:00:18] Netherlands here [01:00:22] I know [01:00:25] oh I don't [01:00:36] you aren't Roan :D [01:00:40] indeed [01:00:51] heh [01:01:27] tommorow [01:01:27] alrighty, sleep well :) [01:01:37] or, today [01:01:39] bye [09:58:37] Krinkle: so what is a plan now? [09:58:57] Good morning ;P [09:59:05] heh [09:59:33] check mail [09:59:41] it seems we are going to have support from wmf [09:59:57] that could solve the credentials issue [10:00:26] if there are going to be some wmf devs they could enable some auth on side of sul [10:04:50] btw Krinkle you have a google mail? [10:05:14] we are not going to use wikimedia until git is working [10:10:53] * Krinkle is catching up with a lot of stuff - brb [10:11:54] Iok [10:13:01] addshore: you around? :P [10:13:26] I would like to know if there is any plan how we gonna work on it now [10:14:02] !pad [10:14:26] !note is http://etherpad.wikimedia.org/Huggle [10:14:26] Key was added! [10:17:58] Krinkle: reply there [11:50:49] Hi [11:58:23] petan|wk, i will be back in 2 hours or so [12:19:01] * IWorld is working on a better, Wikimedia like style :D [12:45:48] IWorld: stop pls [12:45:57] Why? [12:46:01] there is discussion that we maybe implement it as a gadget [12:46:09] Krinkle started it [12:46:10] oh? [12:46:14] :-( [12:46:40] so I don't know how are we going to make it now [12:46:51] actually I don't know anything and Krinkle left few minutes ago [12:47:04] ... [12:47:18] Where is the discussion? [12:47:22] I think it's better to stop working on it, because maybe we just do it all otherwise [12:47:26] in logs [12:48:15] Huggle WA is an external tool... [12:48:26] We have many other tools.. [12:48:33] ..as a Gadget [12:48:40] sec [12:49:58] petan|wk: like that: http://en.wikipedia.org/wiki/File:LupinAntiVandalTool.png [12:51:26] IWorld: ask krinkle [12:51:31] read log [12:51:36] If we are developing Huggle WA as a gadget, we have limited functions [12:51:39] no [12:51:46] he say we can do all we want as gadget too [12:52:18] we compared it and he said it's ok [12:52:51] I do not.... [12:52:56] read log [12:53:06] ... [12:55:47] Then maybe I will not be there... [12:58:04] @ petan|wk: If we are developing huggle WA as a gadget, we needn't an svn, a labs project,... [13:07:01] IWorld: someone move a manual to meta? [13:07:02] why [13:07:27] @ petan|wk: we can develop a Gadget, too. (Like: Huggle Gadget) [13:07:28] IWorld: read log [13:07:32] ... [13:07:40] I need to go now [13:07:49] It wasn't my goal. [13:07:59] this all was answered by krinkle [13:08:21] It should not be a gadget. [13:08:34] I will talk with him. [13:49:39] ok [13:58:54] !pad [13:58:57] !note [13:58:57] http://etherpad.wikimedia.org/Huggle [13:59:04] addshore [13:59:13] what u think [13:59:14] yo [13:59:18] will check in a sec [13:59:22] nweed to get my fish fingers [14:01:09] meh [14:01:29] ok [14:30:34] jljojij [14:30:41] so? [14:30:48] sfjalfjaj [14:30:55] someone here [14:31:10] check it [14:35:22] No, nobody is here. [14:38:25] I am [14:38:26] soery [14:38:27] xD [14:42:38] looking good so far [14:42:59] and im halfway through [14:44:27] I'm not glad. [14:45:45] your not glad? :P [14:45:51] are you being mr oposite today? [14:47:07] perhaps ;) [14:47:45] question is if someone is able to work on it [14:48:04] as I know krinkle if he's going to be only dev for this, it may take few years for it to happen [14:48:20] I don't know java script a bit [14:49:04] well I will hapilly work on the very back end and the very front end [14:49:21] UI and php backend [14:50:21] addshore: I created + - on !note [14:50:35]