[00:58:37] marktraceur: isn't this the Wikimedia channel for support for Microsoft® Office™ products? [01:13:26] Emufarmers: Yup [01:19:27] Visual BASIC for Apps FTW! [01:19:39] * abartov dies a little [06:51:51] Keegan: nice email on wikimedia-l about SUL :) [06:51:59] 2004... not too bad :) [06:54:21] thedj: ;) [21:01:43] #startmeeting RFC meeting [21:01:43] Meeting started Wed Apr 22 21:01:43 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:43] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:43] The meeting name has been set to 'rfc_meeting' [21:01:55] #topic RFC meeting | If you're looking for the staff meeting, join the staff channel. | 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:02:09] #topic Business Layer Architecture on budget | RFC meeting | If you're looking for the staff meeting, join the staff channel. | 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:02:16] #link https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architecture_on_budget [21:02:28] yurik: BLAB, love it, sorry I can't attend [21:02:44] spagewmf, i tried :)) [21:03:23] Hi spagewmf [21:03:44] This seems like a twist on https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_presentation_vs_data_manipulation_line that is hoping to cheat by just using the api.php modules [21:04:01] anomie: are you here? [21:04:17] TimStarling: I don't think he's going to make it [21:04:32] Brad left comments on https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Business_Layer_Architecture_on_budget [21:04:40] Is this office hour on a specific RfC or RfCs in general? [21:05:02] T13|mobile: https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architecture_on_budget [21:05:16] bd808: kk [21:05:23] fwiw, we are using something fairly similar in restbase, with plain JS objects [21:05:26] bd808, that's why i called it on the budget ;) we want to do as little work as possible, while getting the most benefit [21:06:17] I like the idea of decoupling presentation from data, though I'm not sure yet I understand _how_ this proposal does it [21:06:24] so anomie is pretty negative about this, right? [21:06:33] he's not a fan, no [21:06:39] i.e. for titles, what's the difference? [21:06:54] TimStarling, anomie is mostly concerned about amount of work required [21:06:56] SMalyshev: there are basically two schools of thought on this [21:07:11] yurik can correct me if I'm wrong [21:07:27] yurik: I think he's also concerned about the compromises that would be made to get it to work [21:07:30] one is to expose the web API internally to PHP [21:07:30] he is not negative about decoupling biz logic, but he still thinks all code should be allowed to do SQL querying [21:07:47] which i disagree [21:07:57] the other is to have a set of business logic classes that are shared by both the web API and other UIs [21:08:00] yeah, that would negate the benefit of an actual API [21:08:23] TimStarling, correct [21:08:40] all code doing SQL is dangerous. I don't like the idea. There should be model object(s) that does SQLing (unless you're doing something very complex but in this case probably (some) model should know about it). [21:08:55] SMalyshev, i totally aggree [21:09:00] I generally come down in favor of encapsulating database access to some data access object/layer [21:09:05] yeah let's call having all code doing SQL a third option [21:09:35] but in php I like it when the output of that layer is arrays of hashes most of the time [21:09:36] #info very little support for having all code doing SQL directly [21:09:36] which I think is probably the least popular from the perspective of people who like to think about architecture [21:09:51] * troncat agrees with anomie's comments generally [21:09:54] but one of the most popular schemes in practice [21:10:20] maybe it's not even that anymore, you know [21:10:29] TimStarling, i suspect this is mostly due to how difficult it is to call api internally - the calling is messy, the parsing of the result is even messier [21:10:34] we have a lot of business layer classes these days, and new extensions use them pretty heavily [21:10:39] TimStarling: I think common dedicated BL layer is cleaner but if with existing code structure it's hard to do that calling API from PHP can be OK too, given that things like input/output encoding, etc. are handled in some other code [21:10:44] bd808: I prefer plain data too [21:11:19] I think some of the motivation for not using the API data structures directly might come from those structures not being as usable as they could be [21:11:26] also, please keep in mind that if we implement this option, we can easily move the BL to another cluster [21:11:35] yurik, how? [21:11:47] By doing serialization/deserialization behind the scenes? [21:12:05] correct [21:12:09] yuck [21:12:21] bd808: too fast? ;) [21:12:27] I also disagree with the philosophy of "any code should be able to do SQL". There should be a layer we define for that. [21:12:55] not really - because 1) with api you can batch, 2) you can call multiple things in parallel, 3) you can cache in between [21:13:03] If the (de)serialization is done right and works reliably (so I don't have to worry about it) I have no problem with that. Not sure there's a perf benefit, though. [21:13:24] I think the question that yurik is putting on the table is "should that layer be the current apip.php modules?" [21:13:30] perf benefits mostly come in when you can parallelize / distribute tasks [21:13:35] but lets not concentrate on cluster split just yet - its an option that will be available, not neseseraly implemented [21:13:59] bd808, correct - basically i think that we already have most of the BL as part of the API, so why not extract it? [21:14:01] In the past, I've supported the api.php option, but other people have found it unpalatable (though I think the formatters are a big part of that). [21:14:25] does api.php also do input/output formatting/unformatting? [21:14:34] gwicke: db -> object -> json -> https -> array -> object -> use seems ... not so fast [21:14:35] I think there should be a separate set of BL classes which the API uses [21:14:38] If there was a clear, *intended* (not FauxRequest) way to call the API without having to deserialize (i.e. I don't need to do Title::newFromText or whatever when calling from PHP), maybe people will like it more. [21:14:51] bd808, wouldn't it actually be: [21:14:53] TimStarling: +1 [21:14:56] <^d> +1 [21:15:09] I have not changed my mind on this since it was discussed at the arch summit in early 2014 [21:15:12] bd808: depends on how much work you perform on the way [21:15:25] TimStarling, its a matter of naming - api modules have most of the needed components - security, param validation, batching - all we need is call them BL and remove formatting :) [21:15:26] db -> object -> PHP serialization -> some internal network transport (maybe HTTPS ) -> PHP deserialization -> use [21:15:33] if all you do is IO, then yes serialization won't help [21:15:57] I would recommend against using serialize() with anything travelling over the network [21:15:58] although I'm pretty sure serialization is actually the smallest part, a bigger issues is per-request overheads if the backend is also running MW [21:16:04] yurik, and create the convention that it's okay to call from e.g. a special page. [21:16:04] *issue [21:16:06] superm401, lets not concentrate on cluster split - as that will make the issue too broad [21:16:14] yurik, I was just replying to bd808. [21:16:14] superm401: I've done php serialization on the wire before and it is outgrown fast [21:16:17] unless it is absolutely unaccessible by external users (which is not usually the case) [21:16:37] serialize() is not secure with external data [21:16:38] SMalyshev, we have a pretty well-firewalled network. But this is now off-topic. [21:16:58] well, there are still security issues [21:17:05] superm401: The problem is that it locks you into PHP on both sides (or horrible hacks like https://github.com/bd808/php-unserialize-js) [21:17:18] superm401: if you expose api which accepts serialize() sooner or later external data may find the way in... [21:17:24] sigh... please, lets have a separate RFC discussion on the BL split :) [21:17:36] yurik, here's a hypothetical question: If our API output was a bit cleaner (designed around JSON, say), would you still advocate for this over using the API data directly? [21:18:11] yurik: the BL object should not have request processing, no user level error handling, no help messages or parameter declarations. That's part of the web API. [21:18:12] gwicke, my goal with this proposal is for API to output data objects instead of text [21:18:18] We already explicitly rejected that option (PHP can call the API internally, but has to do things like Title::newFromText) in a previous meeting. [21:18:20] correct [21:18:23] thanks Dan [21:18:26] thanks DanielK_WMDE__ [21:18:30] yurik: right, but the question is about different forms of data objects [21:18:41] gwicke, also, if the PHP client now has to do JSON deserialization, that's actually a regression making the PHP client do more work. [21:18:59] yurik: if we can then also use php interfaces to call the API, instead of encoding stuff into strings and pass them as named parameters, that would be great ;) [21:19:01] Right now, e.g. it's exposed as a true array, not as ["'foo', 'bar']" [21:19:05] gwicke: yes, I would still argue that for an object interface rather than a plain data interface, for BL internal to PHP [21:19:17] TimStarling: +1 [21:19:36] TimStarling, take a look at the examples at the end [21:19:57] TimStarling: +2 [21:20:04] can we instantiate those objects from the plain data? [21:20:05] TimStarling, but overall, if we are to have a plugin-based system for the internal api, we need a common way to call it and pass params and get data otu [21:20:29] yurik: that common way is PHP interfaces. [21:20:59] the thing I'm interested in is making sure that we use the exact same data, just dressed up in a more convenient object form [21:21:00] DanielK_WMDE__, I would love to work with you on how you see all the functionality exposed by the present api as interfaces [21:21:06] anything that involves a marshalling step for parameters or return value is bad [21:21:15] nothing will be marshed [21:21:18] marshalled [21:21:23] yurik: at least one interface per module. [21:21:26] that's why data objects are used both in and out [21:21:42] DanielK_WMDE__, but how would you batch them together? [21:22:02] the moment you declare one interface per module, you can't request both links & categories that belong to a set of pagse [21:22:04] yurik: Your examples don't show object going in or coming out. You show arrays in and stdclass out [21:22:11] one philosophical conflict is that the API is stateless, not dependency injected [21:22:24] bd808, i use TitleValue[] [21:22:26] yurik: by creating the appropriate object network. [21:22:32] also Message [21:22:34] the examples make that very clear, with global and static functions [21:22:54] $res->pages[0]->title is TitleValue. [21:23:03] TimStarling: indeed [21:23:09] I think wfApi should be rejected. There's no reason to add a new global function for a key part of the architecture. [21:23:13] I think we should move in the direction of having finer control over state/context [21:23:17] TimStarling, this can very easily be changed to context based - i juts typed the most simple idea [21:23:18] That doesn't seem like the main question, though. [21:23:28] no, you can't really change it [21:23:38] the examples are not finished, simply because they are *wrappers* on top of the API/BL separation [21:23:40] yurik: ok. But you are using a global function taking a bag of values as input. No type checking, no "interface". No way to tell if you are passing the right input or what output to expect [21:23:41] because api.php is inherently stateless [21:23:55] TimStarling, but we are not calling api.php [21:24:04] TimStarling, well, it could be something like: [21:24:10] parallelism is something we should consider as well [21:24:14] $request = new ApiRequest( 'query', array( ... ) ); [21:24:16] the internal system of the api is easy to change to be stateful/context dependent [21:24:17] $request->execute() [21:24:22] both vs. the api & other services [21:24:26] but it wouldn't fundamentally change how the API works. [21:24:41] superm401, true, but not from the external user's perspective [21:25:01] superm401: no, I don't think you can [21:25:23] there is a bottleneck for passing state in your example [21:25:25] gwicke: parallel inside PHP can be made to work but its not a great fit. Maybe in Hack, definitely in node, but those would be services on top of MW, not MW [21:25:25] TimStarling, what specifically about that example wouldn't work? You could pass in the request details (POST array and cookies) as well. [21:25:27] the Virtual Rest Service could maybe help with the parallelism bit [21:25:31] In my mind, there's a central (application scope) registry from which you can get service objects. Service objects are POPOs, you interact with them through their natural interface. [21:25:42] that'S quite simmilar to how API modules work. [21:25:44] bd808: VRS is already implemented in MW core [21:25:51] and supports parallelism [21:25:57] <^d> I worry about performance if I have to proxy my logic through the API. [21:26:06] but instead of implementing al lthe parameter handling, help messages, and return value serialization, you'd skip all that [21:26:10] and talk to the BL directly [21:26:13] <^d> (Just to have it call the same BL class and return a data object) [21:26:22] the question is: what state does ApiRequest need to do its job? [21:26:32] ^d, what performance bottlenecks do you see? there is no marshaling, and the data validation is minimal [21:26:42] everything else is a security check and SQL [21:26:46] this is poorly defined compared to: what state does say ApiEmailUser need to do its job [21:27:11] bd808: https://github.com/wikimedia/mediawiki/tree/master/includes/libs/virtualrest [21:27:12] and the ApiRequest bottleneck is inherent to the proposal [21:27:25] <^d> yurik: Constructing an extra level of object extraction (and method calls) just to return something in a data format I'll have to unwind to use as I need. [21:27:28] there's no point in doing it if you invoke ApiEmailUser directly, you lose the advantages [21:27:52] TimStarling, presumably, it needs the same input info as FauxRequest, just wrapped differently. [21:27:58] the advantages of a stateless interface are parallelisation, network-transparency, etc. [21:28:04] <^d> I generally prefer less objects in a request, not more :) [21:28:05] DanielK_WMDE__, that's more or less what i propose - remove the formatting from the api (into separate class), and call them BL. The wrapper will do the output formatting if its going to external [21:28:26] you can't keep network transparency and also pass state around [21:28:53] gwicke: *nod* a fancy multi-curl client [21:28:53] also, the API needs to expose all the info that's made available through the value objects internally [21:29:16] ^d, there are very few extra objects created -- one per module requested, plus a 2-3 minor wrappers, and I don't think the cost is big enough to outweight the overall benefits [21:29:18] so that network transparency actually works [21:29:38] gwicke, I think the idea is that the value objects would be the API's (renamed to BL's) output, and there would be another layer to format that. But when calling from PHP, you bypass the format layer. [21:30:02] <^d> yurik: I guess I don't see the benefits then. I'm a bigger fan of calling BL classes directly, rather than having a wrapper layer [21:30:05] yeah, but you need to be able to round-trip through the formatter & back to the value objects [21:30:09] superm401, correct [21:30:23] * ^d figures he's in the minority though [21:30:38] otherwise distribution would no longer work transparently [21:30:58] yurik: So db -> array -> value object array -> array -> json for callers of api.php? [21:31:03] ^d, but that's exactly what you will be doing - you will call BL directly, only before that it will pass through a general param validation (which will be very quick if it comes from the POPO self-validated objects like TitleValue) [21:31:03] I think it's doable, just needs to be tested thoroughly to make sure that there aren't regressions in that area [21:31:11] !log reboot round of deployment-prep done [21:31:11] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:31:22] Hm. Silly me [21:31:29] and then there is security [21:31:35] <^d> yurik: I clearly don't understand then. Just ignore me. [21:31:49] if you have all these stateless, network-transparent interfaces, what do you do with all the unauthenticated interfaces? [21:31:53] ^d: you are not alone in confusion [21:32:11] TimStarling: you can forward the cookie [21:32:19] bd808, db -> stdclass -> parsed/converted into BL objects (e.g. TitleValue) and attached to a result tree -> converted to JSON [21:32:24] or a token, derived from the session [21:32:33] gwicke: no, I don't think that is relevant in this case [21:32:53] you are thinking about the non-network case? [21:32:53] yurik: thats's a lot of PHP RAM to eat on multiple copies of the same data [21:32:55] you know an action like editing has an authenticated API and an unauthenticated API [21:33:01] TimStarling, but API is by defininition checks the security of the request? [21:33:17] yurik, why do you need the stdClass step? [21:33:36] because that's how db read returns its data [21:33:39] stdClass per row [21:33:47] the authenticated API works by checking user-related stuff and then forwarding to the unauthenticated API [21:33:47] yurik: individual modules do, i don't think the API framework does this. [21:33:48] it is very short lived [21:33:53] <^d> Not all requests need security to be checked. [21:33:54] yurik, okay, that's not really a separate step then. [21:33:59] except for token checks, i guess [21:34:02] something comes out of the db call. either arrays of arrays or arrays of stclass [21:34:09] superm401, juts wanted to be diligent :) [21:34:20] ^d: isn't that just superuser? :) [21:34:20] the unauthenticated API is a large amount of code by itself, it can't be integrated with the authenticated API [21:34:25] TimStarling: is there a need to even expose the unauthenticated 'API'? [21:34:33] is it actually part of the public API? [21:34:37] No [21:34:49] yes, internally to PHP, it is used by a lot of things [21:34:50] okay, so it's implementation, not API [21:35:05] It seems to me that the biggest down-side of this approach is that it makes static type-checking impossible. [21:35:06] it is obviously not used by external network clients, there is no way to do that [21:35:10] or an internal AIP [21:35:12] API [21:35:13] TimStarling, this proposal is not changing authentication model - if api module allows anon use, it will continue doing so - the important thing is that we can slowly eliminate all the patchy security checks from the non BL code [21:35:41] when I say there is an unauthenticated API, I mean in the other sense of the term API [21:36:07] TimStarling: I don't think yurik is proposing to expose internal APIs [21:36:08] superm401, static type checking can be partially done with the 3rd sample option at the end of RFC [21:36:10] Right, like doEditCount, low-level PHP API. [21:36:14] <^d> overloading of the term "api" certainly doesn't help this conversation. [21:36:20] the set of all public methods etc. [21:36:29] yeah, lets call that 'implementation' [21:36:38] as opposed to 'MW API [21:36:43] ' [21:36:50] Err doEditContent [21:36:57] whenever i say API, I only refer to the ApiMain() [21:37:02] either internally or externally [21:37:08] *called [21:37:08] TimStarling: why do you think the internals are relevant? [21:37:49] the *only* real difference between internal and external api usage is access to POPO objects that DanielK_WMDE__ was talking about [21:37:58] no extra security perms [21:38:13] <^d> I suppose my stance is this. If you want to call ApiMain() internally then by all means go forth and make improvements to allow you to do so. But I don't think code should be /required/ to do so because I don't like the pattern at all :) [21:38:48] and if you are going to change ApiMain() and Brad isn't on board... tread carefully [21:38:55] ^d: it is basically a way to move to narrower interfaces [21:39:03] ^d, we are not talking about "Required" just yet - for that it will have to proove that it can do everything we want BL to be able to do [21:39:09] gwicke, yep [21:39:13] gwicke: I am just saying that there is a big lot of code that can't be mapped to ApiMain [21:39:17] gwicke: really? I feel it'S the opposite [21:39:24] yurik, that type checking is pretty limited (just for input objects). [21:39:37] because if Brad stops fixing the api.php guts somebody is going to have to step up as the caring maintainter [21:39:37] hehe, TimStarling and DanielK_WMDE__ disagreeing on narrowness there [21:39:38] superm401, type checking can be easily expanded [21:39:39] <^d> TimStarling +1 again [21:39:43] gwicke: i mean, you can call eval() a narrow interface, too... [21:40:26] TimStarling, what code are you thinking about ? because if that's the case, we are forever stuck in the php monolyth - and can't move that code to the JS side [21:40:39] DanielK_WMDE__: I wouldn't use that definition of narrowness [21:40:47] gwicke: i think it's really a matter of perspective. of what you consider the interface. ApiMain is a narrow interface on the php level. On the conceptual level, it's very open and borad. [21:40:53] * yurik proposes to switch to eval... [21:41:21] yurik: ApiEvail [21:41:29] err. ApiEval. ApiEvil. [21:41:34] thought so :) [21:41:50] anyway, we should try to extract some common ground [21:41:57] .oO(a freudian slip is when you say one thing, but mean your mother). [21:42:20] TimStarling, sure, but i am worried about your last comment - what functionality is not exposed via api that the page formation logic may need? [21:42:46] DanielK_WMDE__: Tim is arguing that it is too narrow [21:42:48] but DanielK_WMDE__, just to please tim, lets make it a wfApiEvil() [21:42:55] yurik: there should be no such things, ideally... [21:43:20] SMalyshev, that's my point - so i am worried about TimStarling's comment - because that is a serious issue [21:43:23] I'll finish my thought I guess [21:43:35] yes there are internal interfaces that you don't necessarily want to expose [21:43:36] but today there are. Phab is full of tickets from mobile apps say "we can't do X because there is no api endpoint" [21:43:50] implementations in gwicke's lingo? [21:43:56] that's not the same thing as 'expose all the internals' [21:44:07] otherwise we could just expose SQL and be done [21:44:08] bd808: ok, the right question then would be - do we want to have any of those or every instance of it is a bug? [21:44:08] and we have this stateless interface [21:44:12] bd808, correct - and they are very activelly adding that to the api [21:44:26] which like Daniel says, is narrow in a sense and broad in a sense [21:44:30] bd808: because if it's a bug we shouldn't worry about it now and here - bugs are bugs, they get fixed eventually [21:44:49] the question is which we should use as a precedent for further architecture [21:44:54] SMalyshev, of course not everything should have an API. For example, there is a low-level API for adding a log entry. Makes sense to have what we're calling a "PHP implementation", but not an exposed API. [21:44:55] yurik: that are very actively asking for someone to add to the api (/me was the mw-core PM) [21:45:18] superm401, yes, but that interface (IMO) should be called by the BL layer [21:45:23] I think some of the internal interfaces provide a good pattern for further development [21:45:27] not by the page formation logic [21:45:37] superm401: I dunno... I've seen architectures where JS frontend was able to log to backend ... :) but I get what you mean [21:45:41] I don't think this means we are "forever stuck with the PHP monolith" [21:45:56] SMalyshev, this is not log in the sense of log file, it's user-facing. [21:46:04] superm401: I wonder then if logging is on the same level of API as we're discussing [21:46:14] TimStarling: by using the external interface more prominently there would be more motivation to optimize and improve that code [21:46:22] there's no functionality that is needed for page creation that you can't expose via the API [21:46:44] anyway, common ground [21:46:53] good, so there really shouldn't be an extra interface for the internal consumption [21:46:59] TimStarling, the big will with the well-architected parts of the PHP implementations (there are some) is type-checking. [21:47:12] I think it's hard to get good type-checking with this RFC. [21:47:12] API formatting should be separate from logic [21:47:25] TimStarling, that was #1 premise ) [21:47:42] we can agree on refactoring the API modules to make them less dependent on serialization, right? [21:47:43] I don't see how reuse of API modules as a BL layer says anything about making RPC calls from PHP to external services other than once there is a BL layer that could be implemented as the guts of the BL [21:47:58] yes [21:48:10] +1 to TimStarling that is [21:48:36] bd808, i never mention RPC to external [21:48:42] common ground #2: we can agree to replace FauxRequest etc. with some more convenient interface [21:48:43] TimStarling, well, why should we do this if we choose the approach of "PHP clients call PHP implementations"? [21:48:53] Using the meaning of "implementations" from above. [21:49:17] yurik: you had a big ball of PHP argument that sure sounded like that and gwicke was promoting his multi-curl wrapper for parallelism [21:49:18] to make internal calls within PHP to the API be more convenient [21:49:30] bd808, that's not external :) [21:49:38] I think this interface should be stateless, not dependency injected [21:49:44] bd808: my point was that it might be worth considering parallelism in the interface [21:49:50] Won't that discourage people from pulling the logic out of the API into implementations (if we decide that's better)? [21:49:56] so that we can retain the advantages that come with that: network transparency, parallelisation [21:50:05] If we have a better FauxRequest, people might not bother refactoring. [21:50:05] TimStarling: you mean, the request object should be a value object? [21:50:11] bd808, i meant - if all "frontend" php calls BL internally, we could eventually decide to move that BL to another cluster [21:50:21] TimStarling: stuff with dsependency injected can still be stateless. most services are... [21:50:34] DanielK_WMDE__: yeah [21:50:35] TimStarling, I would say we need to have a unit testing context in some form [21:50:41] yurik: at which point it becomes RPC [21:50:46] sure, details [21:51:15] bd808: API calls [21:51:26] TimStarling: everything except cursors and builders should be stateless, really [21:51:29] an API call is not the same as a service object method, right? [21:51:41] Right, latter is what we decided to call 'implementation' [21:52:05] * yurik is still a bit confused about the definition of "implementiation" here [21:52:21] yurik, say like ContentHandler. Just a regular PHP class. [21:52:24] gwicke: tomato, tomato? If the call is to an out of process provider then it is a remote procedure call. API is a the marketing term for RPC over HTTP most of the time. [21:52:44] 'implementation' is everything that's used to provide the functionality that's exposed in the MW API, but not exposed / intended to be exposed directly [21:53:25] gwicke, ok, thx. Important point here - no UI code (either in PHP or on JS) can use any of that implementation, correct? [21:53:30] bd808: there are many flavors; my emphasis is that it uses the declared API only [21:54:17] ok, time to summarise for the notes [21:54:27] yurik: depends on what UI code is [21:54:30] and we need action items [21:54:33] if it's just the formatter, then I'd agree [21:54:52] gwicke, anything that creates HTML out of API results [21:55:13] basically buttons and such, but not wikimarkup->html blob [21:55:19] I think what riles people about this RFC is that it's broader than it needs to be [21:55:20] oh, you are talking about clients? [21:55:40] well, they can use whatever the API exposes [21:55:40] TimStarling, i tried to narrow it down as much as possible [21:55:48] RPC was a mistake to mention :) [21:56:06] the "assumptions" section reads like trolling [21:56:12] gwicke, yes, but PHP code could also be that, and it shouldn't get any extra treatment :) [21:56:18] you could just remove it [21:56:29] TimStarling, never meant that way, Assume Good Faith :) [21:56:31] yurik: yup [21:56:33] The first two assumptions should be pretty uncontroversial. [21:56:42] If we haven't agreed that database queries in UI code are bad, we probably should. [21:57:01] no, it is vague and ranty [21:57:07] TimStarling, assumptions were critical for this RFC, because otherwise we won't agree on anything [21:57:12] superm401: I added an #info earlier [21:57:16] it doesn't say UI code, it says "everywhere", so everyone is reading it wondering if their code is the target [21:57:23] although I'm not sure if any bot is active [21:57:23] TimStarling, its a wiki :D [21:57:50] i write what i mean, sadly its not always read the same way :D [21:58:32] I'd say rewrite it so it sounds less preachy maybe :) [21:58:50] SMalyshev, that's the thing - i don't feel the preachiness :((( [21:58:59] like instead of "it is always bad to" -> "we aim to reduce instances of"... [21:59:00] i wish i did, would improve my comm skills [21:59:22] so, where do we stand on the core of the idea? [21:59:25] SMalyshev, TimStarling, gwicke - could you help with making it a bit more readable? [21:59:36] otherwise there'd be people like "no, I have this one case where it's not bad and I am not letting you say it is *always* bad!" [21:59:37] we will probably need another meeting about this [21:59:40] yurik, instead of "poorly tested", "insufficient test coverage", instead of "dependency hell", "tight coupling" [22:00:10] it's not a complete solution [22:00:18] but we could maybe talk about the direction [22:00:20] gwicke, its a first step imho [22:00:39] I used to like this idea in general, now (thanks to feedback last meeting) I'm more against it due to lack of type checking. [22:01:01] It would indeed be low-budget, but that doesn't necessarily mean it's the right direction. [22:01:23] reuse the API infrastructure, but skip serialization and directly pass around value objects [22:01:32] I'm really not a fan of internal calls that are untyped. And if you make them all typed then you are just extracting business layer classes from the existing api modules [22:01:49] I'm for BL extraction, just not sure this really does that [22:01:53] #agreed make RFC more focused, less preachy [22:01:54] value objects are typed, no? [22:01:54] the most important point here though - it is fairly cheap to implement based on the existing tech. Once done, we could choose to clean it up even further, because by than we will have a clear BL vs UI separation. superm401, please propose the "ultimate best" interface, we could try to move in that dir [22:01:55] +1 to bd808 [22:02:06] it's time to stop now [22:02:14] yurik, best interface depends on what you're trying to do. Just a clean well-designed set of PHP classes. [22:02:18] #info probably need another RFC meeting about this [22:02:28] i agree about untyped calles being bad, but it's slightly funny considering we are taling about php. and mediawiki doesn't even have type hints in many places [22:02:58] let's just switch to Hack :) [22:03:15] gwicke: value object are in and of themselves typed, but the examples are dicts of value objects with magic string keys [22:03:19] we do have partial strong type check - by providing "helper funcs" for each module with parameters [22:03:25] thanks for coming, everyone [22:03:40] thanks for the RFC, yurik, I hope we are not blocking you [22:03:42] * SMalyshev is not that worried about types... [22:03:48] o/ thanks for officiating TimStarling [22:03:52] thanks everyone! no blocks [22:04:01] please help improve any wording you feel is bad [22:04:09] Yes, thanks for proposing. It's important to have ideas to discuss. [22:04:12] #endmeeting [22:04:12] Meeting ended Wed Apr 22 22:04:12 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:04:12] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.html [22:04:12] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.txt [22:04:12] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.wiki [22:04:13] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.log.html [22:04:15] this way we can get rid of what iritates people and concentrate on the propoosal [22:04:16] people write APIs in python/ruby/JS where there is no type checks at all [22:04:29] SMalyshev, not true, Python has very strict type checking. [22:04:40] a = 'foo' + 3 [22:04:43] superm401: not the kind we're talking about here [22:04:47] structural validation is needed in the API in any case [22:04:47] superm401, Python's wiki api is horrible - the most inneficient api i have seen [22:04:59] and without higher-kinded types you can't encode all the properties you'd need anyway [22:05:10] superm401: that kind of type checks PHP gets just in PHP 7 (and I'm not a huge fan of it either btw ;) [22:05:24] SMalyshev, there are static type checkers for both PHP and Python that operate by analyzing the code. [22:05:40] superm401: are we using any of them [22:05:41] ? [22:06:00] not to my knowledge - i keep adding things based on PHPStorm suggestions [22:06:09] SMalyshev: I think I'm less worried about static type checking and more worried about writing a chunk of code that uses this wrapper where there are ten method calls that all require jumping back and forth to the implementation to figure out if I'm passing all the args [22:06:12] SMalyshev, we have type hints, plus the obvious thing that if you call a non-existent method it will fatal (not true with this proposal). Beyond that, some people are informally running type checkers like PHPStorm on our code. [22:06:20] but that's the best tool i know of, that very few at the foundation use [22:06:27] Got to go [22:06:54] thanks everyone, please edit [22:07:10] bd808: ok, I see your point, it should be easy to figure out if the call is ok or not [22:08:23] SMalyshev: In general I'm not a fan of writing Java in PHP. I'm one of the weirdos that actually likes PHP. But I also don't like "pass an array of stuff" as a method signature [22:10:21] bd808: well, yes, I agree it's not ideal but I'm not sure how to avoid it with API that receives collections of stuff... [22:10:36] I don't want to get into generics and all that hell [22:14:32] * gwicke suggests HKTs ;)