[18:56:47] This week's VE triage meeting is about to start: As the topic states, please see https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal for details. We're on a Google Hangout today. [18:59:54] (If you're following the video chat, you have a choice between seeing James' screen and the room - just click on the relevant little boxes at the bottom.) [19:00:08] Hi all, and welcome! [19:00:46] https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal has the link to join the audio/video part of our meeting. [19:00:53] As a reminder, this is what's on the agenda: reviews of release criteria, of resolved blockers and of nominated blockers, then a short discussion about other business. [19:01:12] (and welcome, rdaiccherlb) [19:02:22] we're looking at https://phabricator.wikimedia.org/project/sprint/burn/1015/ right now. [19:02:24] :) [19:03:00] brown bag starting soon? [19:03:38] zeljkof, not in this channel [19:03:43] This will be the VE Burndown Triage meeting [19:04:14] If you want to follow along with what James Forrester will say and do, we're ready to discuss the release criteria listed at https://phabricator.wikimedia.org/project/profile/1015/ . [19:04:49] questions about the criteria? [19:06:07] Now it's time for resolved blockers: https://phabricator.wikimedia.org/maniphest/query/IHomburAWb7W/#R , there are 21 of them. [19:06:26] https://phabricator.wikimedia.org/T91158 was fixed. [19:06:41] https://phabricator.wikimedia.org/T88027 is being described now. [19:06:56] https://phabricator.wikimedia.org/T90420 is something you might have experienced in firefox. [19:07:12] https://phabricator.wikimedia.org/T89066, fixed dependency. [19:07:34] https://phabricator.wikimedia.org/T91772 also fixed. [19:07:56] https://phabricator.wikimedia.org/T70892 , a big one, also gone. [19:08:06] https://phabricator.wikimedia.org/T54936 Parsoid fixed this. [19:08:10] *team [19:08:50] https://phabricator.wikimedia.org/T71482 was also fixed by them. [19:09:35] as well as others https://phabricator.wikimedia.org/T88318, https://phabricator.wikimedia.org/T71950 [19:09:56] https://phabricator.wikimedia.org/T88152 was related to the upcoming Citoid feature. [19:10:27] https://phabricator.wikimedia.org/T91726 was a regression about cursor behavior in tables. [19:10:41] https://phabricator.wikimedia.org/T91827, a change to the toolbar. [19:11:18] https://phabricator.wikimedia.org/T89668 and https://phabricator.wikimedia.org/T60583 are related to the Beta label in the Edit tab, which meant significant performance loss. [19:11:50] https://phabricator.wikimedia.org/T90815 was the last on the list. [19:11:54] Questions? [19:12:35] The nice graph James shows from time to time is https://phabricator.wikimedia.org/project/sprint/burn/1015/ . [19:13:05] To follow the discussion about nominated blockers: check out the left column at https://phabricator.wikimedia.org/project/sprint/board/1015/ . Only 5 nominated tasks this week (which I guess is good.) [19:13:43] https://phabricator.wikimedia.org/T91715 [19:14:03] Implement (part of) the English Wikipedia's edit notice system in MediaWiki core [19:14:12] impressive hack which made VE slow ;/ [19:14:40] Timo will fix this for all of us. [19:15:02] therefore, it's getting accepted. [19:15:48] (as a polish task - which is slightly lower priority, but not connected to Poland.) [19:16:12] https://phabricator.wikimedia.org/T91913 , Category moved into table (and content normalised) [19:16:42] James himself thinks this is a blocker. [19:17:18] it's about edit corruption at fr.wp :/ [19:17:47] (it's different from https://phabricator.wikimedia.org/T74048 , which happened in Safari). Accepted. [19:17:58] https://phabricator.wikimedia.org/T91949 [19:18:03] Visual Editor save dialog hangs, causing data loss [19:18:23] filed by Luis Villa. [19:18:47] the title says it all... therefore let's accept it. [19:18:56] https://phabricator.wikimedia.org/T91608 [19:19:09] Import WikiEditor's list into the Special Character inserter [19:19:24] (BTW, please do test the new character inserter at mediawiki.org!) [19:20:14] The imported list of character can then be customized by each community. [19:20:30] (Also accepted as a polish task.) [19:20:53] Last but not least, https://phabricator.wikimedia.org/T52568 [19:21:05] VisualEditor: Be able to name references manually in the reference dialog [19:21:44] kinda old one, and makes sense that we now look at this issue, which also got recent feedback. [19:22:52] James isn't entirely sure this makes sense given the "demographic" for the next release. [19:25:24] Sherry is explaining a user case where this bug provoked trouble to a user. [19:27:25] The team seems inclined to consider better automatic names for references, rather than the possibility of having users manually choose them. [19:28:00] (We might need to consider how Citoid will change things when it's deployed as well.) [19:28:55] So the team would accept not this task, but a related one as a blocker in the polish group. [19:29:05] (And would like to learn more from this user.) [19:30:41] T92432 is the task being accepted. [19:31:09] https://phabricator.wikimedia.org/T92432 Come up with a better way to auto-label references . [19:31:20] Moving on, [19:31:34] how do you feel about these meetings? [19:31:49] (Anybody unable to join?) [19:32:19] Damon seems to like the new format. [19:33:45] We're currently talking about getting feedback from people who will be interested in the upcoming VE release. [19:34:46] and this is it for the week. [19:35:08] Thanks to the people who were in the call (like ritus). [19:35:36] Keep an eye on https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal for details about the next week's meeting. Bye! [21:00:38] #startmeeting RFC meeting [21:00:39] Meeting started Wed Mar 11 21:00:38 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:39] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:39] The meeting name has been set to 'rfc_meeting' [21:00:54] #topic Service split along presentation vs data manipulation line | RFC meeting | Topic is Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:21] Which RFC, if I may ask? [21:01:25] howdy all [21:01:32] #link https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_presentation_vs_data_manipulation_line [21:01:46] o/ [21:01:54] \o [21:01:55] so this one is a fairly generic one covering best practices [21:02:12] o/ [21:02:12] the idea is to adopt this officially so we can hang other more specific task-oriented tasks off it [21:02:25] I'm a little confused about the definitions. [21:02:37] robla and i did some initial drafting but feel free to comment, we may need to tweak it to make it clear [21:02:40] I would consider the skin system part of the front-end, or at least middle-end. [21:03:05] ah i think we mistyped there [21:03:19] skin would be frontend; storage and manipulation of data would be backend [21:03:19] :D [21:03:27] I don't like having SpecialPages call the API internally, I think that's a hack [21:03:28] i can haz an infrastructure for quick introduction of microservices? [21:03:46] I think an model/view split within the code is a no brainer [21:03:46] legoktm: agreed. They should share a controller [21:04:03] legoktm: that’s fair; i tend to prefer model/view split where there’s both an api and an html frontend that calls a common backend [21:04:09] Why is calling the API a hack? The fact that the API is exposed externally does not mean it can't be used internally. [21:04:09] we may want to explicitly call that out as preferred [21:04:10] but I think the idea of making the view be a service and the model be another service is not so obviously a good idea [21:04:21] We could make it easier to call internally, but that's another issue. [21:04:48] MaxSem: that may be a good one to look at too :D [21:05:02] MaxSem, Swagger? [21:05:34] well, in terms of code structure, there is the problem that the API is not really an API [21:05:56] api.php is a network service interface [21:06:06] agreed [21:06:06] it doesn't provide sensible classes and methods [21:06:10] As to special pages being clients to the API: there's a pattern called "Ineractors". The idea is to abstract the actual logic of the special page/API module, and implement the special page and API module as wrappers around that, which handle request parameters, error reporting, etc [21:06:12] superm401: because the API is basically a front-end to clients that speak JSON [21:06:55] superm401, I'm more interested in lower level, puppet and stuff [21:07:20] MaxSem: that's another RfC [21:07:32] not sure if it is written yet or not [21:07:42] but it's in Gabriel's head [21:07:52] Relevant rant by Uncle Bob: http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html [21:08:09] DanielK_WMDE_, how do you handle default parameters without duplication? [21:08:20] Flow uses a similar architecture right now, and that's one of the problems with it. [21:08:29] gwicke wrote a very similar RFC to this one just before my first draft. I hadn't realized it was there. [21:08:30] sorry my wifi died :P [21:08:34] superm401: interesting point... [21:08:44] DanielK_WMDE_: I approve of this idea of having a PHP interface common to api.php and special page [21:08:53] * robla looks up Gabriel's RFC [21:08:53] superm401: defaults may actually depend on the context, so maybe we *want* to dublicate them [21:09:08] superm401: another approach would be for the interactor to explicitly expose defaults. could be cumbersome, though [21:09:18] superm401: defaults can differ between index.php and api.php, so I don't think that duplication would be terrible [21:09:40] legoktm, in our experience, it rarely if ever differs. [21:09:48] if that's all the duplication (default params) it's a good problem to have [21:09:54] #info consider Interactor pattern for code review between SpecialPages and API [21:09:57] #link http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html [21:10:05] this refactoring of MW core that we're talking about doesn't directly meet the needs of mobile apps [21:10:05] Gabriel's RFC: https://phabricator.wikimedia.org/T88301 [21:10:16] Special pages are not the only case. [21:10:24] seems that if it's a common concern it could be pushed down into the common class [21:10:35] #info DanielK_WMDE_, how do you handle default parameters without duplication? Flow uses a similar architecture right now, and that's one of the problems with it. [21:10:39] Same issue applies to no JS Flow forms. [21:10:52] TimStarling: I would say it is necessary but not sufficient [21:11:13] and I would hope that implementation went along with exposing new stuff to api.php [21:11:27] but do you see other concers? [21:11:33] *ns [21:11:51] well, api.php can only do one thing per request, it is inefficient [21:11:59] *nod* [21:12:02] I like T88301 but I think it should go deeper, i.e. most business logic should be available without the GUI wrapper on both ends, and the GUI wrapper should use the same code [21:12:16] we need either a custom api.php action per app, or a special server-side service for the app, or a generic batching interface [21:12:20] TimStarling: I would actually argue that the inefficiency is in per-request overheads [21:12:33] I like the idea of "thin" aggregator applications for combining api requests [21:12:38] for which batching is a work-around [21:12:44] bd808: +1 [21:12:45] bd808: +1 [21:12:53] TimStarling: if you use a generator, it return multiple modules in one request. [21:12:55] TimStarling: api.php could get a batch mode. encode api requests as JSON. the response would be simmilarly wrapped, with one map for each request [21:13:19] batching definitely would be needed for more complex actions [21:13:23] well, that's kinda what generators are right now, except they only work for page titles [21:13:37] One benefit of an aggregator facade is that it could fan requests out over a large pool of backing MW servers [21:13:40] the per-app api service has benifits in some areas like mobile, it is basically what the new mobile app service is doing [21:13:45] *benefits [21:13:53] yeah, generators aren’t flexible enough [21:13:59] legoktm: would be nice to have generators generalized. Wikidata could use them with entity IDs [21:14:03] but I'd caution against making that the main mode of API development [21:14:07] This is basically what parsoid is doing for template expansion [21:14:25] gwicke: what are you proposing? [21:14:32] #info batching definitely would be needed for more complex actions [21:14:57] #info I like the idea of "thin" aggregator applications for combining api requests [21:15:00] TimStarling: first of all, reducing the per-request overheads [21:15:25] #info well, that's kinda what generators are right now, except they only work for page titles [21:15:32] so optimizing MW initialization? [21:15:43] gwicke, arguably, the network overhead alone will always be too high to have multiple requests for users distant from our data centers. [21:15:55] yeah, that mostly helps internal consumers [21:16:00] network overheads are pretty low [21:16:06] <1ms inside the dc [21:16:17] gwicke: I thought we were talking about mobile apps [21:16:17] So one big problem with api.php as I see it, is that its implementation duplicates various things from MW core [21:16:18] php startup cost is 40-50ms last I heard [21:16:20] gwicke, I wasn't talking about in the DC [21:16:24] they can have whole seconds of RTT [21:16:27] though it can help some of course, especially if the aggregator resolves input dependencies with API calls [21:16:32] Like, often api.php builds its own SQL queries rather than reusing core code [21:16:36] they have per-request CPU overhead in the client [21:16:44] true if we can hit core api faster from an api aggregator service, that’s a lot better than making many round trips from a remote device….. [21:16:45] Because its needs are ever so slightly different (batching, continuation, etc.) [21:17:04] We tried to bridge that gap a little bit with the querypage API module, which does achieve some reuse, but that's not very nice either [21:17:12] there is pretty good pipelining support for a majority of clients coming online as we speak [21:17:17] with the SPDY deploy [21:17:29] * autismcat was waiting for the requisite SPDY plug :) [21:17:30] which basically eliminates the RTT argument for those clients [21:17:49] pipelining only works when the reqs don’t need each others’ data [21:17:55] in which case you could have sent them in parallel [21:17:58] Majority? [21:17:58] I see the main need for custom APIs more in massaging and extracting specific info that's not readily available elsewhere [21:18:04] ...and I guess the RfC on closer reading addresses all the things I just said, never mind :D [21:18:14] superm401: http://caniuse.com/#feat=spdy [21:18:22] as a side note, i'd like to point out an advantage of abstracting the actual backend logic from the API and HTML interfaces: testing the logic (and the wrappers) becomes a lot easier and cleaner. you can text the logic without the representation cruft, and vice versa. [21:18:31] data dependencies between API requests are an interesting case [21:18:32] SPDY is soon to be dead, long live HTTP/2 :) [21:18:36] DanielK_WMDE_: +1000 [21:18:46] brion: +1 [21:18:47] :D [21:18:51] it suggests a need for more logic in the server, right? [21:19:25] TimStarling: simple, submit a Lua script to the API and execute it to generate the response :P [21:19:29] heh [21:19:33] yep [21:19:50] well, you could make a domain-specific language instead [21:19:51] that’s actually…………… EVIL but i love it [21:20:09] but Lua does solve the problem pretty generically [21:20:21] and Yurik would love it :) [21:20:25] * gwicke plots a scheme to use wikimedia's server resources to compute the millionth digit of pi [21:20:28] lua api modules…. fascinating [21:20:29] DanielK_WMDE_: very good point [21:20:37] bitcoin miner? ;) [21:20:45] DanielK_WMDE_: lol [21:20:59] brion: good point, that's more lucrative [21:21:18] well, we already expose Lua to untrusted clients [21:21:21] ok sounds like we’ve got some cool ideas on side services that should get explored further later :D [21:21:22] more seriously, lets be careful to reduce the DOS vectors [21:21:29] and not add new ones [21:21:29] well, Yurik's "give Lua access to the API" idea is really a hack to write SpecialPages in Lua. Which i think is a neat idea. Pushing Lua directly to the API is just taking this one step further. [21:21:32] I haven't heard of anyone using it for bitcoin mining [21:21:50] The suggestio nwas tounge-in-cheek, but perhaps it is something to consider. [21:22:10] ah, well I was about to suggest it seriously before you jumped the gun ;) [21:22:18] hehe [21:22:23] has anybody looked at what Wikia has done re stand-alone front-ends? [21:22:28] scriptable API is exciting but very very dangerous [21:23:09] IIRC they had several experiments ongoing [21:23:30] #info Idea of submitting Lua code to the API to generate result may not be totally crazy [21:24:02] #info scriptable API is exciting but very very dangerous [21:24:12] #info gwicke says SPDY eliminates the RTT argument for mobile clients avoiding HTTP requests [21:24:14] aha, so it's absolutely, insanely crazy instead? :P [21:24:20] #info concurs on dangerous / dos vector potential [21:24:32] gwicke, Lua is easy (by programming language standards) to manage resources for. [21:24:45] That's why we use it for wikitext modules, and quite possibly why Redis also allows Lua scripts. [21:25:00] #info gwicke says SPDY *reduces* RTT argument as SPDY support already fairly good [21:25:13] #info brion says that if there are data dependencies between requests, RTT is still a factor [21:25:22] anyway... [21:25:25] I made gwicke's T88301 "Clean frontend - backend separation; make all frontends API consumers" blocked by this RFC (T89889) [21:25:33] we need project prioritisation here [21:26:03] i would say lua-in-the-api is not the highest prio :) [21:26:16] we need to know if there are product motivations for particular pieces of work [21:26:17] spagewmf: makes sense [21:26:49] TimStarling: Lila is pushing experimental front ends as Q4 priority [21:26:55] so there's the product [21:27:05] I think that will be very useful to drive the API needs [21:27:08] what is an experimental front end? [21:27:13] * Eloquence jumps in [21:27:33] non-MW interface to MW content as far as I understand [21:27:41] think wikiwand [21:27:43] What we've been talking about is potentially having a small team build out new read/search/article recommendations/contribute experiences for the web, relying only on APIs to do so [21:27:48] and of course our own mobile apps fit in that category :) [21:27:51] yes. [21:27:52] brion, gwicke: I'd like more clarity about what "API" and "Backend" mean. To me, the HTTP/JSON API is a frontend to the actual internal logic. Just like the HTTP frontend is, or a CLI frontend (maintenance script) is. [21:28:11] +1 [21:28:20] DanielK_WMDE_: agreed [21:28:24] DanielK_WMDE_: it's also an API in itself [21:28:30] I don't think the API should be considered a front-end. It should be considered a form of API. [21:28:30] DanielK_WMDE_: i tend to agree there; i prefer the data model/logic abstraction to be one step removed from api modules [21:28:33] the term API is a mess semantically [21:28:34] Maybe not a form we want to use internally. [21:28:36] the implementation can be swagged out without users noticing [21:28:38] But still an API. [21:28:49] haha, /me is all swagged [21:28:51] we may want to distinguish “internal business logic api” in some way :D [21:28:55] *swapped* is what I meant [21:29:00] brion, usual term is services. [21:29:06] Services don't have to be separated by a network layer. [21:29:13] brion: HTTP API vs PHP API [21:29:14] *nod* [21:29:19] bd808: that works probably [21:29:20] They can also be pure business logic, but still within the same app. [21:29:20] Putting the HTML interface in front of the JSON API is different from putting the HTML and JSON API frontend in front ob the internal logic directly. [21:29:27] superm401: agreed, but they *can* be [21:29:34] (while the internal logic could be replaced by a stub doing HTTP calls, if need be) [21:29:44] gwicke, right, wasn't objecting to them being separated when appropriate. [21:29:55] Just pointing out it might be a useful term here, if we have e.g. a service shared by special page and web API. [21:30:02] yeah [21:30:13] so nobody is in favour of having special pages do FauxRequest calls to ApiMain, right? [21:30:13] but, one of the things we are interested in is fault isolation [21:30:26] #info Putting the HTML interface in front of the JSON API is different from putting the HTML and JSON API frontend in front ob the internal logic directly. [21:30:31] which is useful especially for experimental developments [21:30:34] there has been some concern in a parallel discussion of "services" already being owned by the -oids [21:30:36] TimStarling: ugh, please no [21:30:36] TimStarling, I think it can be appropriate in some cases (and it's necessary sometimes for now), but clearly consensus is against it in general. [21:30:38] i kinda prefer avoiding the term service because we tend to talk about services being external as opposed to things implemented in the php codebase. but we may just want to clarify [21:31:01] TimStarling: please no [21:31:04] TimStarling: and, more importantly, not the other way around, either (like ApiEditPage) [21:31:25] heh editpage [21:31:30] #agreed nobody is in favour of having special pages do FauxRequest calls to ApiMain [21:31:59] Definitely not the other way around. Not even as a transitory measure. [21:32:13] TimStarling, superm401 : but "Special: page or action calls API internally" is part of the RFC, what do you propose doing instead? [21:32:15] bd808, I think "PHP services" is clear, and will not be confused with either oids, or the Web API. [21:32:17] TimStarling: I wouldn't be so sure that there is such strong consensus on that [21:32:35] presentation layer calling the API sounds like the sane way to do it to me [21:32:40] spagewmf, that's only one of the options listed. See https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_presentation_vs_data_manipulation_line#.28draft.29_Patterns [21:32:42] whether that's over the network or not is secondary [21:32:42] spagewmf, PHP API [21:32:56] gwicke: via in process fauxrequest tricks? [21:32:59] (for the record, anomie will be relieved that FauxRequest is off the table...he'd mentioned he was afraid of that) [21:33:09] gwicke: calling the PHP API makes sense to me. Calling out to api.php doesn't [21:33:14] MaxSem, superm401: OK, so brion needs to clarify or update that part of the RFC [21:33:16] #info we need to clarify internal PHP API vs REST API-via-FauxRequest [21:33:22] bd808: if it's done well, that opens up the possibility of actually moving the API out [21:33:24] FauxRequest does not use api.php. [21:33:28] calling to a* PHP API [21:33:29] I have long thought we should do "Common model/controller" [21:33:37] Draft pattern #2 [21:33:41] TimStarling, gwicke: if there's a PHP interface for the internal logic, it can be implemented locally or as an HTTP, SOA style. [21:33:41] which is good for fault isolation, consuming other services etc [21:34:04] gwicke: ah. but you could move it out by moving the implementation out of the PHP API that was being called as well [21:34:07] REST API via FauxRequest feels ugh to mee [21:34:17] mediawiki could become nothing but an api.php router ;) [21:34:19] Although a REST API via VirtualRESTService might not be that bad [21:34:29] RoanKattouw, ugh still [21:34:29] bd808: the point would be to actually use nothing but the API [21:34:29] Having an abstraction layer (PHP interface) there would give us the freedom to move individual bits to using an external service easily.- [21:34:46] brion: api.php + nice GUI :) [21:34:55] no gui! use telnet ;) [21:35:00] ssh! [21:35:14] * bd808 build ssh into a java app server stack once [21:35:19] bd808, think of all those people in third world! [21:35:29] I don't think we should reject FauxRequest until we have an agreed replacement. And even then, FauxRequest may be needed for a transition period. [21:35:30] MaxSem: mosh? [21:35:35] anywaaaay [21:35:35] brion: ideally yeah I should be able to do with ssh what I do with a browser. [21:35:49] SMalyshev: actually a good CLI mediawiki api client would be pretty handy [21:35:51] superm401: agreed [21:35:59] not sure if we have proposers here to talk about the second RFC [21:36:01] DanielK_WMDE_ [21:36:16] DanielK_WMDE_'s value objects are actually very close to http requests [21:36:16] ? [21:36:16] superm401: the replacement is a controller/model class [21:36:17] ok i think we’re about done with that first rfc for now; got some great notes :D [21:36:28] legoktm, I don't think that's been agreed here yet. [21:36:29] will update it and bring it back ‘round later [21:36:36] in that they communicate just the data in a way that's easy to serialize [21:36:40] so....does anyone want to help on this? [21:36:53] superm401: agreed. MaxSem, legoktm say calling to a PHP API not FauxRequest, but I'm unclear what this looks like. Can you and brion improve the RFC pattern #2 with more specifics? [21:36:55] superm401: A large number of people have expressed support for it [21:37:10] robla: I would help [21:37:16] DanielK_WMDE_: sorry, fat-fingered return earlier [21:37:19] legoktm, there is also the Interactor idea. [21:37:22] #info superm401: agreed. MaxSem, legoktm say calling to a PHP API not FauxRequest, but I'm unclear what this looks like. Can you and brion improve the RFC pattern #2 with more specifics? [21:37:23] np gwicke [21:37:27] bd808: groovy! [21:37:35] sweet [21:37:44] robla: we are already helping with this / working on it ;) [21:38:15] robla: i'd like to showcase code-reuse by factoring out the controller and using it to build an Api module and a SpecialPage. In my copius free time... [21:38:28] robla: well, actually, I could do it for a Wikidata special page. [21:38:44] superm401: isn't that the same/similar thing with just a different name? [21:39:08] I don't know why we so often have gwicke on one side of an issue and everyone else on the other [21:39:14] do we have the rest of the services team here? [21:39:29] i'm here, but joined a bit later [21:39:37] was hunting bugs [21:39:59] legoktm, superm401: as far as I understand, Interactor and Controller are pretty much the same; "controller" may be confused with a UI level controller though, so Interactor may be clearer. [21:40:17] Backend Controllrs are not the same as UI controllers. At all. [21:40:45] sure, naming doesn't really matter that much [21:41:05] Interactor is kind of opaque name... maybe Model Controller or Backend Controller, etc. [21:41:05] DanielK_WMDE_, if you mean controller as in an ASP.NET MVC controller, then maybe interactor is the same as service. [21:41:21] And maybe you're using controller to mean the same as service too. [21:41:31] if anyone wants to talk about "user-specific page lists in core" please say so [21:41:42] because I think we're missing most of the relevant people [21:41:42] All classes are either (a) a controller, (b) a model, (c) a view, or (d) spaghetti [21:41:43] controller as in PAC probably makes the most sense [21:41:52] DanielK_WMDE_: you could reimplement extension/examples BoilerPlate or Example's SpecialHelloWorld using one of the RFC's patterns [21:41:55] * autismcat likes (d) ;) [21:42:06] bd808 and I had a brief backchannel conversation about cat herding, which he's agreed to do for this RFC [21:42:06] I could be convinced of a FauxRequest-like approach [21:42:10] TimStarling, my team worked on that a long time ago, but Gather team would be more relevant now. [21:42:16] superm401: a Service is one level below the controller/interactor. The interactor would be "edit page" and would do permission checks using an Authorisation srvice, page update via a storage service, etc [21:42:21] TimStarling, poked jdlrobson [21:42:28] brb [21:42:34] DanielK_WMDE_: to me this all sounds like implementation detail [21:42:42] * autismcat loves http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control [21:42:45] MaxSem: we can reschedule it for next week, we have a free slot [21:42:54] But I would probably want it to not take the shape of actually faking the request object; but instead passing information to a PHP API, and have the HTTP API be a trivial mapping to that same PHP API, so that calls to the PHP API end up looking a lot like HTTP requests [21:42:54] DanielK_WMDE_: I care more about the interfaces tbh [21:43:03] gwicke: everything is, depends on perspective. they are good terms to get clean separation of concerns. [21:43:33] That way you get the "the interface looks and feels the same benefit" without the ugliness of messing with request objects and faking HTTP requests to parts of the code [21:43:44] IMHO if something is a 'service' it should have a narrow and well-defined interface [21:43:47] spagewmf: should be something that at least somehow interacts with the database, otherwise the example would be silly and misleading... [21:43:59] with only values passing in & out [21:43:59] RoanKattouw, yeah, that goes back to what I was saying about making internal API requests easier. [21:44:10] But not sure that's worth it if people prefer the service/interactor approach [21:44:58] #info bd808, gwicke, DanielK_WMDE all offered to help move this RFC forward [21:45:23] What sort of things do we need to solidify? [21:45:24] superm401: internal API requests imply a mashalling step. would be nice to avoid that, and make use of the languages and IDE's capabilities for checking types and method signatures. [21:45:54] DanielK_WMDE_: that’s a good point! [21:45:54] DanielK_WMDE_: not necessarily; in restbase for example we perform internal api requests without serializing [21:45:59] fauxrequest vs PHP API? Is that still a topic of debate that needs research? [21:46:05] DanielK_WMDE_, yes, type-checking is one of the downsides of the FauxRequest-like debate. [21:46:09] let's split the actual FauxRequest from some new but vaguely HTTP-like interface as options [21:46:15] gwicke: but you still go via array structures, no? [21:46:16] with pure php interfaces we get type checking; fauxrequest has to take an array [21:46:24] DanielK_WMDE_: pure value, yes [21:46:41] no deep references to random other objects [21:46:42] because I don't like FauxRequest itself but I don't mind the idea of other forms of internal routing [21:47:11] WebRequest is a big bundle of stuff, it's not just GET parameters [21:47:18] Yeah [21:47:21] And even if it was [21:47:23] gwicke: so still a conversion, and loss of the language's built in method call features. [21:47:41] If we can avoid lying about something as consequential as the request object, we should [21:47:53] DanielK_WMDE_: we don't really convert but just build up requests [21:48:08] How does the room feel about smart objects like User? [21:48:13] #info with pure php interfaces we get type checking; fauxrequest has to take an array [21:48:22] bd808, against them. [21:48:31] * gwicke concurs [21:48:34] DanielK_WMDE_, yep )) [21:48:35]