Hello and let's talk about secularism. Now, according to the preamble to the constitution, India has a sovereign socialist, secular and democratic republic. However, a few days ago, Maharashtra Governor Bhagat Singh Koshyari sent a letter to Chief Minister Uddhav Thakre about temples not being opened due to the ongoing COVID-19 pandemic. In the letter, he wondered if the Maharashtra CM had turned secular, a term which Uddhav Thakre, according to the governor, used to hate. Of course, the Maharashtra CM replied with an equally scathing letter claiming that he did not need a certificate in Hindutva from the governor. These barbs aside, what does it mean for the country when secularism is used as a taunt? We have seen this all around us, the eye-rolling when secularism is mentioned, the abusive way in which the word pseudo-secular has been used. And now we have a constitutional functionary using the word in a way that makes it seem like secularism is not really a value to be cherished. What does it say about the polity and the state of our institutions? We talked to senior journalist Paranjay Guha Thakurtha on this issue. Thank you, Paranjay, for joining us. So we have seen the governor of the state of Maharashtra Bhagat Singh Koshyari write this letter. And this letter is a lot of media organizations have also already pointed out, experts have pointed out that there are various aspects which are problematic. But to start with the most significant issue here seems to be his question to Chief Minister Uttar Thakure as to whether he has turned secular, which of course the tone is one thing. But the sheer question itself kind of sparks disbelief because it seems like being secular is something of a crime. It's something that is deviant to something like that. So what do you have to say to this? Prashant, this is really absolutely amazing, the kind of unsolicited advice that the governor of Maharashtra Bhagat Singh Koshyari gave to the Chief Minister of Maharashtra. And you see both of them are constitutional authorities. That's the first point. The most controversial sentence in that letter that he wrote, which is it's in the public domain. Again these letters, who pulled it out in the public domain is another issue. But dripping with sarcasm, Governor Koshyari wrote that he was wondering whether the Chief Minister has received any sort of a divine premonition to keep postponing the reopening of religious places in Mumbai, in Maharashtra, and then wondered whether he turned secular himself and he said this is a term that he hated. Now the point is, if you look at the facts, Maharashtra has among different states in the country, it has the maximum cases of COVID-19, over one and a half million cases, over 40,000 deaths. Health, law and order is a state subject. Technically the governor is bound by the advice of the Council of Ministers. But whether it be in Maharashtra, whether it be in Kerala, whether it be in Bengal, the governors who have been appointed by the Bharti Janta Party are acting as if they are political personalities, not constitutional authorities. In fact, this was pointed out not just by Uttar Pradesh himself, that the Governor Koshyari had sworn by the constitution of the country which mentions the word secular. And the head of the Nationalist Congress, Bharti Sharad Pawar II, has written to the Prime Minister, objecting to all that he's written. Now behind all this is politics. Governor Koshyari was literally made a fool of when he had sworn Devendra Padnavis and Ajit Pawar early in the morning and the whole political equation changed. Now if you step back and see the photographer's son, the Thakre's cartoonist father, Balasat Thakre, was a hardcore right-wing pro-Hindu political personality. You can't say the same thing about his son. But Balasat Thakre was a different guy.  I mean when the anti-Muslim riots took place in Mumbai in 1992 and 1993, the Sri Krishna Commission report clearly pointed out the complicity of the Sheikh Sena in those riots. But let's move ahead and let's see Uttar Thakre. Uttar Thakre talks on the, it says on the floor of the Assembly that one should not mix religion with politics. Now they are obviously very, very unhappy about the fact that they've been denied this opportunity. The Shiv Sena and the BJP were together before the elections and then they lost out because Uttar Thakre switched sides. Now we have to also know that local elections are going to take place. Now after having taken charge as Chief Minister, yes Bhagat Singh Koshyari reminds Uttar Thakre that you've been a strong rotary of Hindutva, you had publicly espoused your devotion to Lord Ram by visiting Ayodha after taking over charge as Chief Minister. All of this is Sagar Grace. Now it's sort of competitive Hindutva that is in place. The same Devan Koshyari welcomes actor Kangana Ranaut when she could describe Maharashtra compares Maharashtra to Pakistan occupied Kashmir. So what we are seeing is competitive, you know, sort of right wing Hindutva and I just say the unsolicited advice that has been given by Governor Bhagat Singh Koshyari indicates, I mean how even today the Bharti Janta Party has not been reconciled to the fact that they failed in their attempt to form a government in Maharashtra which is one of India's very large and highly industrialized state at the capital of Maharashtra. Mumbai often described as India's financial capital that they have lost out. I think it's still hurting Governor Bhagat Singh Koshyari who's acting more as a functionary of the Bharti Janta Party than as a constitution of quality which he is. Absolutely and this context is also maybe interesting to look at the aspect on which much of like you said the sorghrabs is focused on that is secularism itself and we've already seen how much in public culture secularism is today denigrated. I mean pseudo secular has almost become a common place in popular discourse so to speak on WhatsApp and families on media channels of course. And now we have a constitutional function like you said say seemingly in this letter which is again sarcastic almost making it seem like it's something that is out of the ordinary. So these kind of small small these this letter maybe in the larger scheme of things is nothing it gets forgotten two weeks down the line but it also sends a message in some ways about how secularism itself is being perceived and its value being in constitution. You mentioned the phrase pseudo secularism. This was used by Lal Kishan and Vani. You know but the point is today the crisis is deeper because what you're seeing is that the very the constitution of India it's itself under attack and there is talk that is there's need to remove two words from the preamble which is secularism and socialism. The point is the Narendra Modi government clearly by its actions are I mean they have indicated in the past and continue to indicate how little they really care for institutions and how little they care for say the parliament the manner in which the last parliament session took place that the I mean if you compare the track record of the Narendra Modi government the last six years the two governments with the way parliament has been it's not to just mention various other institutions of the state whether it be the judiciary whether it be bodies like the election commission of India law enforcing agencies like the the the central bureau of investigation the judiciary the media all these institutions have been not just compromised and weakened they've been populated with individuals who espouse a certain ideological position which is not just pro-Hindu but more often than not Islamophobic and this is the culture that is being sought to be propagated by the ruling dispensation and the supporters of the ruling dispensation so what you're seeing this kind of unseemly spat and exchange of letters between the governor Maharashtra and the the the chief minister of Maharashtra is really a manifestation of how the Bharti Janta party is ideological parent the Rashti of Swamseh Baksang and the rulers of India today how they are seeking to not just demonize the seventh of the population but what what what what they actually are I mean they're completely disregard for secularism any which way you choose to interpret this term thank you so much for talking to us thank you our next segment is part of a conversation between newsletters Prabir Purkayastha and immunologist Dr Satyajit Rat they discussed monoclonal antibody therapy which was given to US president Donald Trump after he contracted COVID-19 Dr Rat explains his treatment and its positives and negatives right now of course the news is the monoclonal antibodies not a cocktail but two anti-bond monoclonal antibodies seem to have been given to Trump in a mixture and Trump claims this is amazingly good that he is almost fully recovered and he's also pushing that it be now allowed for under emergency use provisions which earlier he had proposed or he had advocated for hydroxychloroquine and what else was it apart from bleach which of course he didn't really ask for emergency authorization he had pushed Remdesivir he had pushed plasma therapy do you think this monoclonal antibodies the Regeneron variety of course which is given a huge boost to their stock is actually something which is worth considering at this stage that this is something really which has more positive elements to it for whatever reports we are getting and not from Mr Trump but from whatever other reports that are available and it could be something which could be used yeah so it's interesting in a variety of ways this monoclonal antibody cocktail therapy that's under trial and that Mr Trump has gotten as a matter of compassionate usage authorization compassionate usage presupposes that one is feeling sorry for the ill person so let's let's go one step back and remind ourselves that for a long time not simply Mr Trump and his fantasy bandwagon but a lot of people across the world including in India were very hopeful about plasma therapy right and the principle is being used in different parts of the world including India and in India we had politicians exhorting people who had recovered to donate plasma and so on and so forth now let me offer a little bit of arithmetic in this the amount of plasma being given in plasma therapy was about 200 milliliters okay 200 milliliters of plasma is on average about four grams of antibody protein okay but keep in mind that of the total amount of antibody protein that anyone of us has circulating at any time certainly no more than about one percent will be against a given target okay that means amongst the antibodies the which is your currently what the disease or infection will be you will be having only a small fraction of the total antibody only that small fraction will be against the specific disease correct so think it's about one percent sort of four grams you are really talking about really 0.04 grams correct so now consider that unlike plasma therapy the monoclonal antibody therapy that mr trump has gotten has a two dose regimen a high dose and a low dose he of course being the leader of the free world got a high dose regimen so the high dose regimen is eight grams the low dose regimen is four grams okay what this is saying is that in the low dose regimen four grams of monoclonal antibody is injected into the individual now unlike plasma therapy here is the arithmetic when you do plasma therapy you are transferring 40 milligrams of antibody when you do monoclonal antibody therapy you're transferring four grams of SARS-CoV-2 specific antibody that's hundred times more effectively monoclonal therapy is giving 100 times the amount of antiviral antibody as plasma therapy has been given okay yeah i think it's antibody that you are getting getting to replace really help your body antibodies to fight the disease now so effectively the antibodies that you're getting are substituting for your antibodies they're not actually helping your antibodies do anything okay they are simply functioning to neutralize virus particles binding to target cells and if that happens the virus life cycle is interrupted and if the virus life cycle is interrupted virus growth is prevented and that helps you get better so what Regeneron the company has done is taken not one but two monoclonal antibodies both of which block virus particle binding to the cell surface and the amounts that are being given are huge not only are the amounts huge they are therefore being given as a slow intravenous drink so here's the problem what we are talking about is an extraordinarily expensive medication okay because such very large amounts have to be given consider the manufacturing and the supply chain difficulties that will arise for one dose to be of four grams or quite possibly eight grams that's one problem the second problem is as i said intravenous strip so it has own it can only be given in a hospital hospital the third issue is we've been saying now for the past six months that for all viral diseases antiviral medications have the most clinical effect early during infection as a result what we are saying is that the Regenkov II which is what this medication is apparently called although Mr. Trump seems to think that it's called Regeneron but which is the company but this monoclonal medication where would it be best so let me point out to you where it would work supremely well it would work beautifully as a prophylactic as a preventive in people who are going to be very high risk exposed such as first responders such as healthcare workers not simply physicians healthcare workers including physicians nurses nursing aides ambulance drivers mortuary her drivers and so on and so forth in them a single injection might quite conceivably provide them with very strong protection for a couple of weeks or even up to a month but the trouble with that is they can't just take a shot and go to work they have to go into hospital get an intravenous drip all of this therefore is to underline the fact that none of this none of these are easy solutions there are interesting technological possibilities but there are daunting real life difficulties with all of this none of this of course does the current president of the united states understand in any nuanced fashion but nuance has never had a being any passing quintance apparently with Mr. Trump that's all we have time for today we'll be back tomorrow with more news from the country and the world until then keep watching news click


I'm going to tell you a short story and the story is about the UN Framework Convention on Climate Change or the UNFCCC. Article 6 of the UNFCCC is on the issue of public information, dissemination, education and capacity building and it's a very uncontrovertial article of the UNFCCC and in the negotiations the negotiators who follow article 6 usually the developed country negotiators, they send their junior most negotiators there because there's nothing controversial happening there. It's an up, up, up, up by a motherhood issue, everybody proves some complicated education, dissemination and capacity building. So usually it's a very uncontrovertial track of the negotiations but unusually just before the Paris negotiations, the 21st Conference of Parties in Paris in 2015, it became slightly controversial and the reasons for the controversy was the fact that all the capacity building that was being done until then was being done primarily by developed countries funding consultants from developed countries who fly into developing countries for a few days, run a few workshops, fly out and take the box on capacity building. And in the developing countries, particularly the least developed countries, there was a very strong feeling that this was not enough. We need to be investing in long-term capacity at the national level and this fly-in, fly-out, consultant-driven exercise was not enough and not sufficient and in fact one of the research institutions, ODI, tracked the numbers of how much money has been spent on this and it's in the region of $300 million has been spent on so-called capacity building entirely spent on consultants from developed countries to come into developing countries and run workshops. So in the Paris negotiations, this particular issue for once became controversial with the developing countries, particularly the least developed countries, arguing that we needed a centralized UNFCC driven long-term capacity building program and not just leaving to the developed countries to run it the way they like, which they have been doing until then. The result of this was that in the Paris Agreement, we have now a new article, it's article 11 of the Paris Agreement on capacity building, it's a new article, it doesn't exist before and it says that the emphasis now needs to be on building national capacity building systems that are sustainable over time, the Paris Agreement timeline is in 2030, we need to be investing in national institutions and one of the neglected national institutions that we all have are universities. As I said earlier, the $300 million that has been spent on capacity building, almost zero went to universities, most of it went to consultants. So universities already exist, they may not have the capacity now, but they can be invested in to develop their capacity. So coming out of the Paris Agreement under the leadership of the LDC chair, I took an initiative to contact a number of other least developed countries, friends and universities, primarily the Mukri Macarelli University Center. We agreed to collaborate to jointly form this consortium. We are going, the initial consortium is 10 universities in 10 least developed countries and we are using a hub and spoke approach for each of us to then engage with others in our region so that we cover all 48 LDCs, there are 48 least developed countries and the instruction from the chair was that we have to include everybody, we cannot exclude anyone, but on the other hand we cannot do all 48 at the same time, so we start with 10 as a core group and then the 10 will reach out to the others and we will cover all 48 and the objective of the entire exercise is a south-south initiative driven by the LDC of countries group in which we will empower and enable universities to be doing capacity building for the long term and make their countries able to tackle the impacts of climate change. One of the focus areas for us because we are vulnerable countries is obviously adaptation and then within adaptation one of the focus areas is community-based adaptation working with the most vulnerable and hence the CBA conference is one of the most relevant for us and hopefully we will continue to be engaged with future CBA conferences from the LAC initiative. Colleagues and friends, when it comes to capacity building, I think universities are certainly the best, best institutions to do that. We have I think about four universities in Uganda, a few government or public but very private, so we will bear the torch and we will ensure that all the other universities know what is going on with this initiative. Capacity building is a critical, if you look at the countries that are involved, I think a good number of students and a number of those that I know have prioritized capacity building, so I think we are just on the right foot. We will expose the young and the old, the young going primary and secondary schools, we will use the opportunity to create the information and the required training materials so that we can go through all of them, through all of those medications and really since then and before those upcoming scholars, upcoming researchers about climate change, its causes, impacts and what we can do to mitigate what is happening. We will also engage in research and innovations and that's why I hope it was created so that we can put information to policy makers and also increase the body of knowledge about climate change. We are focusing on adaptation but where mitigation also comes, important I think we will also try to make contribution. At the chair of the LBC group in the United Nations Framework Convention on Climate Change, I have been trying all my best to move the group from a victim's narrative into a proactive champion on climate change. One of the most important aspects of becoming champions for tackling the impacts of climate change in the LBC is the need to move in the long term capacity building at the national level in every LBC country. During the negotiations of the 21st conference which was held in Paris in 2015, the LBC group argued for and achieved the inclusion of a new article which is now article 11 in the Paris Agreement on the importance of investing in long term capacity building at the country level in every country in the order to tackle the impacts of climate change effectively around the world. I also feel that it's very important set for institutions at the national level are universities which have the role to build the capacity of the teacher, leaders at every country. So far there has been very little investment in enhancing the capacity of universities to learn build the capacity of the people of each country. It's therefore an important development for the least developed countries that the black initiative has been developed as an LBC specific South-South University initiative focusing on adaptation as well as other climate change related topics. Let me conclude by saying that although this is an LBC initiative we are very open to collaborate in order to collaborate with LBC both from the South as well as from the North as we believe that knowledge sharing is a two way street in which we can learn from each other. Thank you.


All right, welcome. So in preparing this session, I wasn't quite sure what to actually talk about. So there were a lot of proposals that were grouped in this topic area that are all very specific to specific APIs. And I think most of them have found a home in breakout sessions already, things like feedback sessions about what do you want to get out of the search API. And so I don't think we need to talk about those here. And instead, I would propose to talk about the high level picture and direction of where we are going with APIs. I'm open to suggestions, though. I don't have a lot of material myself to present. So if you have specific things you would like to talk about, please speak up. So let me give you two slides of introduction for the high level questions that I think would be interesting to discuss. And then we can launch into the discussion. So this is a short overview as I see it of where we are. So we have a lot of new functionality that is being built on APIs. The request volumes are going up. And latency is important because a lot of latency sensitive services depend on these APIs. And as apps, there's increasing the web using APIs and as a lot of third party consumers as well, which we want to encourage to use these APIs because we want them to build on top of all the content that we have. So we need to support this growing volume and ideally do it at low latency and need to figure out how. The two main APIs that we have right now are the Action API, which is the traditional and API and service most requests. It's very powerful, started out as an edit interface and has a lot of additional functionality on top of that. And the Fully New Rest API, which doesn't have that much functionality and is mostly focused on content access at this point. And now we also have some smaller service API like Boris that are standalone. That is basically one API per service and are now tied into one overarching API. There's some differences between the main APIs with regard to caching in particular. The Action API is mostly based on query parameters that aren't necessarily all at the same way. So it's very difficult to cache and purge. So as a result, there's mostly no caching in API responses. It's very much an RPC model. And on the other hand, REST is deterministic URLs normally, so the default is caching, varnished caching, which helps with latency and scaling. Documentation and testing, that's orthogonal to those that are two different choices that we have right now in implementations. One is using Spagger specs versus a custom documentation system that has additional features that Spagger does not have like localization. And there's some implementation differences. Paracrest CPU over has differed quite a lot. They are not necessarily inherent in the platforms that are used, but there are a lot of factors that play into that. But they are quite significant. If you look at it like 35 milliseconds versus roughly half a millisecond per request, that's not nothing. Yeah, that's a slight difference in the processing model as we work over per request by default versus asynchronous event loops, which is relevant for proxy use cases especially. So here are some of the big high level questions that I think we could tackle in this session. The first is REST versus RPC, which direction are we moving in? Are we longer term moving to a REST model so that we can cache most responses? Are we what kind of versioning do we use for the API? There's currently two different approaches. In the Action API, there's a format parameter where you can select the format, especially the JSON format, to use or to return. While in the REST API, there's several parts. There's a major version in the path. And each endpoint has a stability marker. Endpoints start out as experimental off and then gradually move towards stable. And the promise is that a stable endpoint, if it has changed in a breaking way, the major version has to be incremented. So you can basically rely on a stable endpoint keeping working. And there's content type headers with spec versions in them. So you can find out what exactly, if there's no non-breaking minor changes in the content that is returned, you can find that out with the content type. And finally, well, not finally, but the number of APIs that is the discussion we had several times now, basically new services like Aura's can expose a separate API. We can keep doing that for each new service. And the other extreme would be to have one unified API that binds them all together and has one way to discover all this functionality and has a unified monitoring and all these things, or something in between where we find some compromise. And finally, if we manage to establish agreement on where we're moving, how do we get there? While they're in small steps towards those things without obviously rewriting everything from scratch. So these are my proposals. Should maybe switch to the etherpad. So I think that one API is probably not a very good solution. The REST API is really good at giving you information about one thing, one page, or one image, or one whatever it is. Whereas the Action API is optimized for giving you a piece of information about many pages. If you have an arbitrary set of 500 pages, it's really hard to query that in a REST API and have it be done in any sane way and it would probably blow up your caching. Whereas that's exactly the use case that a lot of our bots and user scripts on Wikis tend to have. So I think that we can pretty easily have both APIs that serve these different use cases. There's definitely different trade-offs between batching, which generates especially providing very rich functionality where you can generate one list and then apply an operation in one, though, one request. On the other hand, the REST model is you do a lot of very small but cheap requests. So it basically puts the burden on the client to do a lot of this iterative work. Actually, I know the mobile apps want to do very few requests. And so some of the stuff they're looking at is making a REST API that gives them all of the information about one page that they need to do their whole page display. Yeah, it's just a composition of other requests again. That's a good use case for a REST API because you're accessing the information about one thing and you want it heavily cached. That wouldn't fit all that well in the action API unless we look into something like varnish X keys or something that we could have an endpoint that actually was easily purgeable. There's even in the REST API, there's also post end points that let you do things that are not casual at all, like converting your custom wiki text to HTML or your custom HTML and modified HTML to wiki text. So it's not completely mutually exclusive in a way. It's REST too. It's a post endpoint. But I guess what I'm most interested in is should most of the content, all the high traffic entry points that people hit all the time for standard tasks, should those ideally be cacheable? It depends on what the people are doing. Yeah, right. It's basically about can we push it to all those where that is a suitable pattern? Because I think by volume, all the high volume ones are fairly straightforward given me this information. While the more complex interaction patterns, those are bots. I mean, they also have high volume. But I think that that volume is not going to necessarily go that far up. Some bots really do hit a lot of requests. But they do things that wouldn't really benefit from caching. So caching isn't such a concern. I don't know that high volume is such a useful thing as to whether it's so performance sensitive and that it makes the same requests over and over again where caching is important or not. Yeah, it depends on what you build on top of it. If your main web front end is hitting this API, then caching is pretty important. Yeah. Brian, I think you guys actually mostly covered the things that came up here to say. I do think that the REST versus RPC question is maybe a false dichotomy that there are many and varied and complex use cases for programmatic access to the content held inside MediaWiki. And things that are more content export oriented typically align with a REST API pattern with something where there's a noun that you're asking for things about the noun.  And the Action API is a bit more, it's not the most beautifully designed API that anybody's ever had in the world, but it's much more a kind of a cursor oriented like give me. I want to know this aspect about a varied set of content and I probably don't know exactly which content I want, but I have some kind of search or discovery mechanism, some sort of query that I'm going to present to you that says come back and tell me about all the things that happened related to these things. So I guess what I'm trying to say is that there are good uses for both patterns and it really depends on the particular consumer that's trying to be to satisfy which type is built. I guess as I said earlier, the question is more if we, for endpoints that are more of the type, tell me about the cat or the dog, should we use REST for those or should we use something that cannot be cashed for everything, I guess more the trade-off that we can actually. I think you're going to have a hard time finding anybody who says that more caching would be bad as long as we can find reasonable performance ways to invalidate said caches, right? One of the three hardest problems in the history of the planet. One thing I'd like to be clear about is when you say REST versus RPC, are you referring to the RESTful APIs versus RPC APIs, or are you talking about specifically the action APIs, paradigm versus the... Mostly talking about basically everything being opposed or some similarly opaque and difficult to cash request, where you can't hook into a standard HTTP cash semantics, but have to maybe still get to do some caching at the application layer further down, but it's a lot more complex? I think if you look at the action APIs surface area, it feels much more high level than the RESTful API, but you could implement that on top of the RESTful API. So you could have essentially a client library for the RESTful API that looks and feels almost verbatim as the action API does, and that would essentially give you both options with a single carrier mechanism. Yeah, I agree, especially where we move more work to the client. If you provide that code out of the box in a toolkit, then you iterate over things, and there's already toolkits like PAE, Wikibod, and so on that do some of this iterative stuff, then I agree, then you can get a similar feel in the end. Well, you could get a similar feel, but I think that you would run into more performance problems trying to emulate all the things that the action API does using our REST API. Yeah, I agree, that's definitely cases. Which goes back to the point that both APIs are good, and I don't think that we need to try to say we only need one. Yeah, okay, but I think that they serve different purposes, for sure. I mean, the two APIs that we have right now, they serve different purposes, and they're both very legit. Honestly, we had to do very simple interactions with MediaWiki, and the action API seemed like an overkill in some cases, and mostly, I mean, I never took a look at it, and some things looked like counter-intuitive for the casual user that I was, so I think that for a casual user, so somebody that just wants to build something on top of our data, the RESTful API could be much better if you want to do some quick proper prototyping, and that's what RESTful is good for, right? It's simple, there are some things, anyways, that REST, because it's built on top of HTTP properly, cannot do, for example, it's supposed to be stateless, meaning that you can just, you can't properly keep state between requests, so one of the things that, historically, people implementing just REST APIs have problem with is transactions. I'm not sure that we do transactions right now in the action API, but we could, in theory, just allow people to do transactions with requests, while it's, let's say, philosophically wrong with REST API to do transactions. I think that for, we are now moving a lot to use REST API in general between our internal services, and that's going to present some limitations on the wrong run, maybe, I mean, I've seen quite a few projects moving away from REST for their public interface, I mean, some data stores that are trying to use, for example, GRPC, which is a new standard of RPC interactions that Google published as open source, which is basically implementing on top of HTTP2 a lot of things that it's kind of hard to do with REST, usually, so making promises and timeouts and managing timeouts explicitly from the client side and the server side, which is one of the problems that we are, we were thinking of tackling, right, to get really, if you think, I think it was a ticket written by you about this exactly, so, I think for the public, the REST API is important for people that just want to consume data quickly from mid-weekly or that want just to build, I don't know, simple clients, especially for reading, I think it's great. I think that probably the Action API has a big value for people doing more complex things that need more rich interactions directly, and those people are typically, I'm not worried about caching for people doing complex things because complex things are going to be hard to cache or maybe even, let's say, painful to cache because they, I mean, I don't expect many people to ask for the same set of 500 articles at the same time, right? So it's probably going to be more hard for the good to cache those, and that's why the REST API that goes just by entity, by single entity is easier to cache and that makes sense in that case, but even, I would say that, okay, this is about how we interact with the public right now, so as people outside of, we can make the cluster interact with our content, and I agree that we need to keep both APIs. I would like us to think about a little bit if we want to keep moving with REST interfaces for everything within our cluster, so within the various services. I think we should consider going on if that fulfills all of our needs completely or if we have to think of moving, let's say to an evolution of REST in some ways internally, and that's a part of the problem, I mean, probably for simple things like, I don't know, mathoid, which does just one simple thing, REST is good enough, but if we start to move more things outside of a main blob of media wiki, like bigger things, or let's make a stupid example, right, image conversion, you might want to do, to have media wiki called an external service to do an image conversion or transformation, and you want to come back later to fetch results and you want to be able to define in a clear way what happens when a request times out where it is not fulfilled in the time that you want to serve the result to the client. In those cases, probably if we keep REST, it's going to be a limitation in the long run, so. Yeah, I think there's lots of solutions out there, large companies having often their own frameworks. Google has their, some are using REST actually, some are using various frameworks, but it's a big step, I think that's the main issue with moving to a different framework internally. It has a high cost as well, so they have to be compelling advantages. But yeah, I agree REST is not the most efficient or technically best thing ever, it's just ubiquitous and yeah, easy to understand for anybody. So one of the things I'd like to suggest is that we, I mean we can keep going on the REST conversation, REST RPC conversation. One thing that I would like to do as well is A, just provide a reminder on what this area as a whole is meant to be, is about basically getting access to our content, getting data in and out of the system. Regardless of what format it's in, we've got the content format area to talk about that. This area is about the infrastructure around the content and how, and the APIs are central to that. So I wanted to provide that reminder there and then as a follow up to that, I would like to ask, there was a session earlier that Dan and Andrew were leading, but there was a lot of people in that session.  Sure, so we generally talked about this general concept of data flows, collecting, processing and serving data and how it relates to like how that is done by different teams, search, fundraising, research, analytics and different requirements from all of those different perspectives and efforts on Event Bus and kind of trying to, mostly the consensus was that pretty much everyone thought the problem was similar enough that we wanted to work on it together and similar enough that Event Bus could solve all the different use cases but that we needed to collaborate and start working on it together. So do I need to clarify any of that for anyone? Because I used words that I don't know if everyone knows Event Bus or things like that. Raise hands, I don't know. It's a REST API for Kafka, essentially. Actually maybe just a further clarification on Event Bus because I know that, so I'll, yeah. So I'm just asking for further clarification on Event Bus because I know that we've had at least some mailing list discussion in the past about what is Event Bus and how relevant it is, is it to this area and so that, yeah, I think maybe just a little bit more. Sure, so the general idea is that you want to structure all the data that's flowing in the similar paradigm so that everyone can understand what to do as a consumer, what to do as someone who's interested in different streams that you wanna join different streams or whatever. So the main idea is all these data pieces that are flowing through this system should have a schema so that consumers can understand them so that we can go back in time like two, three years and be able to consume data that was produced then that we might not remember what the code looked like. So factoring out this metadata in the form of a schema is one of the primary things. And then from that point, really, Event Bus is just making it easy to produce events in those schemas to a stream and not so much worried about the consumption part because that can get tricky, but just kind of generally having the streams there so people can join them or do whatever they need with them and sort of standardize how all of that works. And one example that might be interesting is the search team wants to integrate things like page rank or page view statistics in how they rank results. And so having a stream of that kind of data is useful for them. And knowing the structure of that data is accomplished by the schema. That's a concrete example. Any other session summaries? So I was curious about the number of APIs. We talked about two APIs having good reasons, but we have recently created a couple of new services and they're separate APIs for those. What is your take on that? I mean, the trade-offs are possibly user friendliness and discoverability versus independence of how the APIs are designed. So now, oh, there it is. I wanted to reply on some of the earlier comments. So one thing that was brought up is being able to do batch requests in the Action API. It's a very important use case for a lot of bots and tools that need data. But well, one thing that does maybe reduce any of that a little bit, and I'm not sure to what extent we can expect this to be ubiquitous in tools, but HTTP2 and speedy by extent do allow for a lot more easily to have parallel requests or in other ways to batch more data. And the other thing is what we're seeing now in REST Base as well is that it can compose data objects without needing to fetch them again, right? Just because you make a batch request to REST Base doesn't mean REST Base needs to do a batch request at the back end. It can fetch the individual object that it already has and use them. But it does bring up in what way we want to do caching. So right now, if I understand correctly, we don't really utilize Varnish for REST Base caching. I don't know if it completely by masses it, but at least it's not like the main purpose to be cached there because we want to cache it in Cassandra instead if I understand correctly. No, it's mostly relying on Varnish. There's some issues still with login requests, so that's a task to fix that. But all the high traffic stuff is basically relies on Varnish. Okay, that's interesting. And so yeah, so what I wanted to bring up is basically using REST Base as a composer versus REST Base as a proxy. So there's various services that we now bundle into one process that run essentially as one HP service. But there's also services that REST Base includes but also doesn't include in that they are exposed there, but actually run as a separate process or as a separate service entirely, but are proxied through it. So they're still exposed through it. And I think that's an interesting model that we can explore more. But it does bring up like what we wouldn't do with storage. Like do we want the individual storage to be, do we want the individual storage or do we want Cassandra behind REST Base to do the storage for like long-term things. So separating those concerns is a good sign. Yeah, I guess it's a little off topic for the API part only, but it's definitely important for the system design. I think one, it's a lot simpler to scale and manage stateless services. So there's a strong incentive to keep state auto services. Some of that was the idea with REST Base originally. I think there are limits to that. We shouldn't use one storage layer for everything. And there definitely shouldn't be access, direct access from one service to the other services storage so we can change things behind its back. That should be clear ownership. Yeah. And I think right now most of the use cases that REST Base serves are basically cash-like use cases. In some cases, it's authoritative because it's bound to a user session, for example. And we can consider using it for actual storage or for actual content, authoritative content in the future, but that's not why it's used right now. Yeah, but there's also AQS, for example. The Analytics Query Service has its own Cassandra cluster, its own storage. Which one, sir? The Analytics Query Service for HV Data has its own Cassandra cluster and they write to it from Hadoop and are independent in their management and that has worked very well. So only proxies for REST, but it isn't stored inside REST Base's Cassandra cluster? Yes, yes. Okay, I'm sorry. So yeah, there's kind of this dual role of aggregating APIs and presenting one unified API to the outside that REST Base currently fills, but that can also be implemented for really high traffic endpoints and something like Varnish, like we can tee off this traffic too directly to the backend without it ever reaching REST Base. But it's more about what model do we want to expose to the developer in terms of documentation? Should it be one path in one general API or is it a separate domain, for example, or a completely separate branch for a different API? I just wanted to make a quick point. One of the things I liked about, so we worked on the Analytics Query Service and one of the things I liked about that experience was the modularity between the storage and the API level. I think that's really, really important. We did run into problems with Cassandra, both computing data to stick into it because it needs everything pre-computed and serving data out of it while it's being loaded and lots of things like that. We solved some of it. We're still working on some of it, but we love the flexibility that we can just say it's easy from REST Base to implement like a Druid module or a PipelineDB module and query that instead. I think whatever kind of APIs and things we develop, we should always think about that modularity because you never really know until you hit scaling issues or query issues or whatever. I have a question regarding performance. So did you benchmark reading from the REST Base API via reading directly from Hadoop? So I mean, that could be comparable in theory, but it would be interesting to see how those compare. Dan, that seems to be analytics-specific. I did not benchmark Hadoop. You don't really want to query Hadoop. So we didn't even try. It's not a system that you want to be responsible for keeping online with a level of reliability that an API would need. And yeah, latency. So there's no real, I mean, it's got to start up the VM and do all this stuff every time you ask it anything, so. Also, we only have one Hadoop cluster that's important too, yeah, but yeah. I think a separate storage layer, a separate presentation layer for the data makes sense from a lot of different points of view, both data model, and I mean, there's like databases very specialized for time series, for graph or whatever that you definitely want to use. You don't want to just go against Hadoop. Just a comment on just API design. And one thing I've noticed, that's the difference between the REST-based approach and the MediaWiki action API approach, and just in terms of having more granularity in the endpoints and more restrictions on what you can request individually allows you to have more robust documentation on like the response type. So you actually have a schema that you can say is guaranteed for a specific version of an endpoint, which is kind of orthogonal to REST versus action, but the action API in its flexibility in allowing you to compose different data objects in the same response makes it exponentially more difficult to say like this query that you just made up has this schema and has these properties that are guaranteed, whereas REST-based can say very explicitly, this is what you're gonna get. This field is optional. This field is an integer and things like that. And the ability to granularly, discreetly change that schema over time and enforce backwards compatibility is nice that REST-based has considered that more important from the get-go. And I was not saying that's something that we couldn't explore in the action API. I think it's just one thing that in my experience is nicer to work with as a developer. Still no comments on the number of APIs? I was on a walk talking about APIs before I walked in the room. So like could you maybe kind of restate that question? So we have a lot of new services and some of them have started to expose their own API like Oris right now. And you could follow that model of each new service having potentially their own API, different domain or a different sub branch under slash API slash service name. And the other extreme would be having one API that assembles them all, has one unified form to document it and then there's obviously the current state which is somewhere in between where we have two APIs. So I'm mostly wondering about should we push or not services to integrate into one larger API or two larger APIs or should we encourage separate APIs basically? Oh, OK. So when you say one API, you mean one domain that has a bunch of specific endpoints underneath it that are like well-described? Yeah, something where you have a unified documentation so you can discover what is available. You can browse it. And of course, this could also be built on top of multiple separate APIs. But I guess the question is how uniform those would be. So those are the trade-offs that I see. But I'm going to weigh in. Well, so I have a sort of a different question. But I'll save my question for a second. Yeah. Just to speak on the kind of multiple APIs, I know one of the things we ran into, especially when I first joined and even up to now is just just, oh, Corey. And I'm on the mobile apps team. But yeah, the discoverability of the APIs, there's so many people have worked on so many things and they're so disparate. And like I said, multiple domains, like discoverability really is a problem. I can't think of how many times we've come across like, oh, we really need an API that does this only to mention it in passing. Something like this is like, oh, that's already been three times. And here's where you find it. So I think whether it's actually one URL or how it works, but the discoverability I think is really important. I think some sort of source documentation and however we do that, I think that's kind of like, this is a level up from this. But I think that's kind of important. Boom. OK. This is working. Yeah, so I don't think that there's like a perfect answer right now. I mean, the API.PHP documentation is usually not bad. In most cases, people who are creating an API.PHP implementation could document their interfaces better. Yeah, we don't right now have the ability to easily state what the output looks like, although I'm sure that would be possible. But yeah, generally I'd be in favor of having most of the high-performance internet-facing APIs more centrally available for discoverability purposes and for developers to be able to see things and allow API.PHP to change faster. It's easy for people who are building front-end code for the Wikimedia properties, for example, to adjust their stuff for API.PHP on the fly, but for people who have package implementations or suppose they're a third party and they need to have like a highly reliable interface, having like a central place of documentation would be better. So I don't think like there's a simple answer myself. Well, speaking about the ORS in particular, I just wonder if some of the reason behind them having their own API was because they implemented it in labs and you can't have a production service depending on labs. And once they move it into production, then I hear that they're looking at integrating in both REST Base and the Action API. Speaking of ORS, I think that basically because it's written, it's a completely different project. So it has its own API, of course, and you can probably integrate it into REST Base or any global API endpoint that you want. But I want to say, I can't hear you, Marco, sorry. OK. Anyways, I think that there are good reasons for having both unified API for most things. I mean, at least the things that more people would like to use for building clients for our rich data set, right? And for having single purpose specified API for the single service, because that's, of course, going to be more flexible and can have a different format than it shouldn't necessarily conform to the standard that you should conform to if you want to have an unified API. What we need and what we don't have, that's what Corey said before, is we don't have a good site for documentation. Unified documentation of all of our APIs, it's not, I mean, when I try to search for information, I have to go around searching for information and we should probably spend some time and maybe even have somebody do that. The microphone, oh, OK, it came back. We should probably have somebody doing that work explicitly, I mean, documenting all the APIs that we expose to the public. Because it's a lot of things. I mean, even the Wikidata query service is an API if you want, right? So we should really have a single place where a developer can go and just look around at all the APIs that we offer and have an unified API for most things, which has a standard structure that's unified for everything, logic in itself. Hi, I'm Steven. I'm on the mobile apps team as well. I wanted to make sure that I understood the question. So would another example of multiple APIs be the differences between querying content on, or sorry, retrieving content on Wikipedia versus Wiktionary? No, sir. I would consider those different sites and you can have the same API structure for both of them. So whether that is part of a parameter or whether that's just a different domain and expose the same API, whatever path or API.php, I would consider that the same. The question is more different bits of functionality. For Wiktionary, for example, the query part should that be a separate service and a separate API with a different structure, potentially, or should we try to unify at least the ones that are generally useful into one coherent API, or at least gradually nudge things in that direction? So it's kind of like how great it is that you can do a query on Wikipedia and then run a similar query on Commons, is that right? Using mediaWiki API. Yeah, at least for all the features that are common between the two, which is a lot. I think from the perspective of a developer that is really focused on solving a particular problem, it's absolutely wonderful to have an API that is in the same terminology of the particular site. So for example, if I'm on Wiktionary and I say define the word dog, I probably have a pretty good idea of what that is just by looking at the endpoint. How many is that? Can you give an example for what differ between Wikipedia and Wiktionary? Perhaps for Wikipedia, the example is article. The endpoint is article. And I say give me the article for dog. And that gives me the full content of an article, or give me the card for dog. And that gives me a small amount of data that I can present in a card-like interface. And some of these, I think, would be common. But having different APIs or allowing different APIs would make it much easier, I think, for developers focused on a specific problem for a specific installation of a specific site. But to clarify, you mean slightly different functionality. So you get a different response. For example, on Wiktionary, you would get a definition that has, as we were actually just discussing, a summary. Well, on other sites, maybe you would use a summary that has a lead paragraph and then page image. Yeah, personally, I don't really think of developing a really generic app that just works with every single MediaWiki install. I think it could be done. But as a developer, I'm really interested in focusing on the content or the data at one site and developing an app for that. Yeah, Stephanie, I agree that whenever there's different needs and different functionality, it should be named differently. There's no point in confusing people by naming the same and actually doing something different. But there's also cross-cutting functionality, like just give me the HTML for this page as it is rendered. That can probably be named the same if it's doing the same thing.  So I think, generally, what I would recommend is separating the, because I completely agree with Stephen. I think you have an API surface area, which is the actual things that you call, the functions you call, and they're different in action and REST based. And there could be specific ones for OREs and things like that, but separating that from the actual transport mechanism, client-side libraries. What we do is we have a GRPC that's used internally for absolutely everything, and then we have protocol buffers that define specific APIs for specific things. So if a mobile application needs to talk to its back end, it can communicate directly via that mechanism and using a predefined protocol buffer. So essentially, the only thing that's different between specific APIs is APIs are the actual surface area, which is the protocol buffer and the code that implements it, but everything else is standardized. And that makes discovery easier, it makes implementation easier. You don't have to think about, is this RESTful, is this that, which client library do I use, where do I go to look for this thing that's all standardized, and it makes it much simpler. And it also allows you, by virtue of being centralized, to enhance, to add things like HTTP2 caching and stream reuse and things like that that grossly simplified the effort to build a new API and to use an existing API from a new front end. I think the API spec work is actually also moving in that space, it might not be quite there, and there might definitely pros and cons. But I think the point in time where that was making your own was the only way to get all these benefits. And I think it has changed a lot since then with HTTP2 and with specs that have been developed since. So I think REST is no longer so cold as it used to be, the cold world out there. Okay, I just want to remind everyone that we have less than half an hour left. So refocusing our efforts on what we want to achieve is good, but I also want to bring up two points. One is, so regarding the merging of services behind REST-based, I think it also brings up an interesting point with regards to focus of scalability and uptime. So I think it will be a pretty big difference for something like Aura's, whether it is behind REST-based or not in terms of how many instances you needed that service and how exposed it is. And it goes in both ways. On the one hand, if REST-based is highly reliable and highly available, it would cover a small short outage in Aura's. But the other way around, if Aura's were to expose directly, it wouldn't be affected by downtime in REST-based. So those two also are playing some, like, can you still serve content when one is down? This would of course be simplified when you have something like Varnish which also covers those kinds of gaps. But I just want to bring it up. Yeah, also for the isolation, having one cluster versus multiple clusters so that you can avoid one deploy, wiping it all out and the procedures around deploy is all playing to it. Just a comment, since this is my area basically, that's exactly the problem that I posed about having a proxy in front of everything. We already have Varnish for good reasons. I mean, multiple proxies. It may be good for functionality, so for presenting a unified API, but it's surely not a good thing for stability. There's no way it's a good thing for stability. I mean, there's no way. The good thing is that a path-based structure makes it fairly easy to rewrite or map specific requests or specific backends and something like Varnish. But the downside is that you get more complexity in the Varnish configuration, basically. So you want to keep the number of entry points and all that Brandon has been doing work on making that more streamlined, registering basically path prefix and mapping it to a backend that would help, basically. We could still expose it as one documentation, but have the request go straight to the backend without ever touching respace. So I think that could give us the best of both worlds. It looks the same to the outside, but it actually goes straight there. But I think that's a long tail of low requests, not very critical endpoints where it might be okay to just go through respace. Yeah. So I also mentioned earlier was having a shared place for documentation on different APIs. And indeed, as has been working on this, on Media Weekly at ORC and myself as well on Wikitech. But a more significant effort on that is also the developing hub that some people are working on, which is somewhat comparable to what you would, for example, see with developer.google.com where you have a shared interface of all the different products that we have and the APIs that they expose. So that is definitely in the work for those not, but I'm personally working on. My second point was this, when you have a unified interface, you also have unified versioning. So it gets a little bit more tricky in how you deal with major breaking changes when everything is under one API. You also have one API version number, at least the way it's currently structured. That can also be something that can really quickly expand complexity in how different people have the authority within the API. Because if everybody's in the same API, then who actually owns the version number? And how many times do you wanna keep breaking things and rerouting things? And then you get a lot more cache segmentation of things that didn't change and stuff like that. Yeah, it's related to the discussion about pair entry point versioning versus global API versions. You can have both, but that gives you the flexibility to keep both up and working. But yeah, one paths are one option, while other parameters could be another option. So that's a lot of, generally you can push, as we've experienced in the action API, we can push backwards compatibility pretty far by being only additive and so supporting the old requests. But yeah, that's always going to be breaking changes. We so far don't have pair entry point versions, but we're considering using accept headers. But right now, as it is documented, the stable APIs would force a major version increment, which has the problem you bring up. Something else I was thinking about when we're talking about the usability of the APIs is that as developers, when we get started, it's pretty much important that we understand the relationship between the sites and then some sites are more coupled to others than others are. So obviously all the different language sites are for Wikipedia are extremely tightly coupled. And that kind of goes with commons as well, whereas some other project like Witchinary is a little further off to the side. So as a developer using the API, it's kind of odd if I'm looking for Wikipedia content and then I have to get images and then I'm going over to the commons API. So in a situation like that, it might make much more sense to have a unified API, whereas if we're talking about some other side project like Witchinary or something like that, it does make more sense maybe if they are separate, but it's kind of like something to think about where it might be more of like a case-by-case basis, but I mean, and this goes more than just beyond developers to like our perception from the public of like we're basically seen as Wikipedia and we have all these other projects and it's hard to understand how they all relate together. And I think the way we do our APIs also shows it's like also confusing to us and how they relate together. So I think when we think about restructure in our API, we should kind of think about that perception of how we want these things to be seen and how they should be seen to the outside world. We, there are some technical issues there, but I totally agree with your point. That's just that we currently don't have a mechanism in place to deduplicate all this at the caching layer, for example. So if you expose the same image through 800 APIs, 800 domains, then you have clearly have to deduplicate that. So one API means like under one domain or it just means, because you're talking about like proxying between all the different services or something, so is that like one domain or does that mean, I'm still not really sure what that means, I guess. Yeah, there's two ways to look at it, I guess. One is the API structure, which would be the same for German Wikipedia versus English Wikipedia versus French Wikipedia. But then there's, so that is one way to say this is one API, it's one structure. It's one spec, but it's exposed at three different or 200 different domains. Or you could treat one domain as one API. And you were talking about routing based on path prefixes, but that would be for like different services that might be internal and exposing instead of proxying through REST base or something. I'm talking about varnish routing. Well, you can bypass, yeah. You can base on path prefixes, you can bypass varnish, REST base and tell varnish to go straight to the back end. And the outside doesn't need to know. I mean, you just see a URL and... What's the benefit of doing that over just using a different domain and routing that way? Oh, domains are fairly expensive. If you are a client on English Wikipedia, you have a connection open to English Wikipedia, you have to domain DNS resolve to English Wikipedia. So you better, if you want to have a fast response, you better use English Wikipedia for your API as well. You want to minimize the number of domains you use and the number of connections you have to open, especially with TLS. That's several roundtrips, fair connection. And that's basically the limit, in fact, all the motivation for having these APIs at slash API, something. We have 15 minutes left on the timekeeper. Okay. Yeah, well, and that's one of the things I wanted to make sure we talked about, because this is about content access in APIs and I wanted to make sure that we didn't just focus on the API as being the only way to get at the data. Ariel ran a session earlier about getting at the dumps and how we generate dumps of our data. Yeah, so just the summary. One of the main ways that users get at our data is they download XML or SQL dumps of tables or revision and page content. And there are more and more data sets that are being produced over time as well. These dumps get slower and slower to run. And at some point, the old architecture organically grown has gotten just very difficult to maintain. I hate dealing with it anymore. So the idea is if we knew what our users saw as flaws or were missing and we could toss the old system all together and just solve it ideally, what would that look like? Reusing as much work as being done here as possible. So the event bus was one of the things that came up repeatedly. One is a way of distributing jobs out to different nodes. And another as a way that we could make incremental data available because people beg us for incremental dumps. They wanna have a full snapshot and then they wanna just see a feed of what's coming up in two days or five days, what's changed instead of having to download and process this whole huge thing again. So those were the two event bus uses and oh, already I'm forgetting.  I'm jet-legged, I promise it's not the speakers. Anyways, there were several other suggestions that were very helpful. Trying to think of maybe having pages with their revisions together in HDFS. And every page is a separate item, so regenerating a dump just looks like deleting old pages, putting new pages in and then some packaging that was up for download. Anyways, a number of different ideas. You can find the etherpad. Please chime in, there'll be a project called Dumps Re-Write, at least hopefully that'll be created and so I would encourage people to get on and help us make those better. There's also HTML dumps that are experimental. We talked about them, we talked about them. See, this is why I'm dead. We have multiple formats coming out from different sources. We want it to be easy, so instead of I have to write a whole different set of okay, how do these get generated and how often we index them and this and that. It should be one infrastructure that just, you say, here's my source, here's the script that runs it, here's where they live and then everything just happens. So the HTML dumps were absolutely a prime candidate, their prime example. Those are currently using SQLite databases so it can be updated in place, basically. Random access, but downside is you have to download a full database, you can't stream it. So Gabriel, I'd be appreciative if you could help tease out the question I'm about to ask and it has to do maybe with a long run vision of both a universal translator and engaging, perhaps, Wiktionary in relation to Wikipedia, to Wikidata if that was something, for example, that World University and school could further. How would this paradigm work in terms of maybe a unified, a generally unified API scenario that you were mentioning? If, as Daniel Kinsler said just a half hour ago, that Wiktionary is in the works for both text and spoken language in the future, would the versatility of this API, I'm not a programmer, be able to be applied from Wiktionary, say, to content translation to a from language and a to language in Wikipedia in a particular article, is how to conceive of these various APIs within this unified API structure as one gains more significance hypothetically, brainstorming-wise is my question, I think. I'm not sure if you're after word to word correspondence or if you're looking for text translations. What is the use case? The use case might be to go from a Mandarin Wikipedia article or a MIT OpenCourseWare course in Wikidata in Wikipedia into an English Wikipedia article from that Chinese or Mandarin or from a MIT OpenCourseWare into English. So for article translations, we have the content translation project which is very nice, provides a nice user interface and uses machine translation to support the user. So if you start out with a machine translation, you can fix it up. So that would be my suggestion for articles. So all are unique domain APIs in one sense and is that my understanding from what the previous speaker right here just asked to conceive of content translation as well as Wiktionary as well as each Wikipedia language as separate APIs or you consider, could you consider all of Wikipedia, one API, vis-a-vis all of Wiktionary, one API, one versus content translation as yet a third API? I'm trying to clarify in my own mind how APIs, this sort of scheme of them, work together. I'm not sure I understand the question completely. I think this content translation has a separate API right now, you're right. But your question is if they can be integrated or what is that? More and more fully integrated in different ways. I'm Scott McLeod. Well, they can be definitely when we are in conversation with the content translation team. But there's concerns around they're using third-party translation services and we don't want to expose those to the world necessarily. So thank you if you consider those. Just also like say like also work on OpenStreetMap and the way like they handle like diffs and like dumps and also like the APIs, I think. Well, maybe not perfect, but it's like, it works pretty well. Like the changes, like they're stored as like change sets like in the database and then they provide like like minutely, hourly, like daily, just different incremental like dumps as well as like the whole thing. And then there's like tools that like pretty easily you can slice and dice or like apply like the changes to keep like your copy up to date. So like, I think there's a quite a proliferation of like third parties like, well, Matbox now are like us and like providing like services and like tools and like as well like their API, it's like a REST API which is like version six, but it's been around for like years and has been like stable and so like, I think that also helps like people like build stuff around it and just allow it to get like used pretty widely. So it's, I mean, at least for Wikiday and like something like having like the structured diffs and like providing them incrementally, like I don't think would be like so hard to do, but like still needs like some sort of infrastructure and stuff and just time and time to get that done and like someone to get that done, but yeah. That's also a lot of interaction between the APIs and the incremental updates, for example, if you just distribute the list of changes you might have a REST line just run these updates by hitting a REST API. So like in terms of domain names, like how many distinct domain names we need, like I guess for myself, I would probably prefer to see something like www.wikimedia.org slash API I know that we've like had the REST.wikimedia.org domain in the past, but getting that to be consistent so that users when they land on projects in the future or operating off of one domain might simplify certain things that might help us become more aware of things like DNS poisoning. It also would simplify things I think for developers in general. So I'd be kind of interested on that front. I do understand like right now that's very much impractical because of the nature of how skins are rendered more or less on a per domain basis or how experiences are rendered on a per domain basis and there's certain assumptions. But yeah, just that's kind of like where my thinking is that I think it'd be really neat if when somebody comes to read an HTML page in the browser if it were served off of a singular domain and that might be bootstrapping some sort of API backed experience, whether it's done at server composition or if it's done by a client orchestration. Yeah, but I'm not sure how that works like from an ops perspective. If we actually standardized on one domain name kind of across the board. I don't want to conflate having the API endpoints with serving the HTML, but I think like inevitably that's probably like the simpler approach. Yeah, we currently have upload and we have WDW media wiki.org actually for some global data like AQS, yeah, page view data is exposed there. But yeah, the main issue really is number of connections. If you are mainly on English Wikipedia and you also do some API requests then you just need to open extra connections if it's a different domain and that's on a slow connection that's a second or so. Just your TLS set up several roundships, maybe some packet loss thrown in. Right. That's very expensive. With multiple domain names, right? So yeah, I heard you earlier on like standardizing for both like older user agent implementations and ones that are even newer. Like I think it's like generally that's good. I wasn't sure though like in terms of whether our kind of VIP architecture can handle like an arbitrarily large number of sockets to the same domain name. Maybe that's a non-issue in our environment. I don't, maybe somebody from hops could speak to that. Like suppose that we wanted to unify everything under one domain name with the projects being like path based underneath that like both on the API and on the HTML website side. Or do you know? Yeah, people will still go to English Wikipedia for only unless we can tell them it has to be ww slash en which would be a big change. Yeah, I realize this like there's a convoluted step, a bunch of rewrites that happen right now. And maybe that's just the way it will always be. I think Timo's proposal to have an entry point across projects that directs people to all these different resources that are available. I think that it seems to be a lot more practical in the short term, including you should use comments or images, this kind of information. That's, I think, yeah, I think the point that we have to treat this as an outsider, we don't really know what these projects do. As an insider, we, yeah, which in a way it seems obvious, but to an outsider, not so much. Yeah, they don't need to necessarily reside on the same domain to be discoverable through one domain as HTML can point to anything. And so that can be really powerful. In terms of reuse of, I think it makes sense to keep wiki specific APIs exposed under that wiki's domain. If anything, to simplify connection reuse and just being able to contextually discover it when you're already on that particular project. So, a.nzv.com.org slash api now gives you what you would expect. But if you're a high traffic consumer that consumes a lot of different wiki media projects and content, I think internally we will probably always be serving different projects as being one service, right? Like we don't have a wikipedia server, we have a media wiki app cluster and they're essentially presented as one service. And the same for REST-based. Like REST-based takes the domain essentially as a parameter of a longer resource. It's not in any way more significant than the page title or the revision name really. And so if you want everything for one domain, we all can already do that. That's what REST-based that we committed to work is for. So for that domain, you can do them all on one if that's what you want. And if you just need one, you can use that one. So they both work the same. And I don't know if they're already doing it, but if not already, we can actually also trivially share the same varnished cached object even. We currently already do that with project domain slash static. They're actually all cached as one object in varnished. It just ignores the main part. And so it allows some kind of rewriting and cache reuse even at the varnish level, even though they're presented on different domains entirely. Yeah, if it's uniform, then it can be one rule, basically. Yeah, right now, the policy with REST.vickimedia.org is really discouraging using it because we want to encourage people to use the same connections, but it is still available. So if we think this is, I mean, it is only one API, so we probably want to have a wider integration for the discoverability part. But, yeah, maybe revisit it down. Well, the connection reuse goes both ways, right? So if you're using this Wikipedia already, your reuse connection will be contextual things Wikipedia, but if you're consuming 100 different Wikis, then your reuse connection is actually going the other way. In that case, you probably want to use REST base as your one domain. Hi, do you have use cases in mind? Yeah, so actually, I do. From the Contravinalism project, we fetched different, it's basically a service that runs in two labs right now, or in Wikimedia Labs, I should say, it's its own cluster right now, but it makes API requests to many different Wikis based on whatever recent changes happen across the whole RC feed input from basically all public Wikis. And so it doesn't do it right now because it uses the API to PHP still. But if I migrate it to REST base, I can see myself using REST base at Wikimedia.org and we use that connection throughout the whole process. So I think in that other questions raised there, I think I've got a summary of the things that we discussed and so there's like the long detailed minutes and then there's just the brief summary, like if you needed to write a trip report for this or something, like this would be the piece that you could cut out and say, this is what we talked about. Did I get it right? Like is there something, and I guess maybe just as a follow up, like this is, this will probably be the headline for, this is what we talked about in this meeting. So I think that we can, as far as this summary part and so to the extent that then we can follow up on which of these questions is really truly important for us to answer and which of these questions is like shrug, like we don't care so much. Like I think that that may be what we should be considering for the coming weeks and months. Yeah, I think the discovery part definitely is a very central one that was brought up many times and different and it's very interesting to change the perspective to look at it from somebody who doesn't know anything about the Wikimedia universe that I think is a very important point that I took away. Well, we don't want to stand between all of you and lunch. So, all right, thank you.


A precious point saved at the end there, you started well but you seemed to struggle to create some chances there through the middle part of the game, was it kind of a frustrating evening for you? Yeah it was a little bit, I mentioned that to the boys at half time, we felt that we really started well the first 25 minutes or so, and we did threaten them a few times and we were pretty happy the way that we started the game, so our intent was to start like this, but we did fall back a little bit and a little bit frustrating, but all in all a good point, a good reaction at the end. When you look at a game like that in balance, I think Moe had a very good chance in the first half, hit the crossbar, there was a couple of opportunities that we could have done a little bit better with the last cross or last pass, but the way that we finished the game was strong and it was determined, it was positive and I see it as gaining a point. Rustiness there at all, I mean Mariners have already played a couple of games and I'm sure you don't want to use that as an excuse but you obviously weren't at your best? No, it's not an excuse, it's an environment that we're in and we're wanting to make sure that we started the way that we finished, but that's always a little bit difficult and challenging because we were in a very good position then, we had seven games and improving every week, so for us the momentum was taken away from us at that period, but it was our first game back for four months and the good thing for me is that the willingness not to lose a game was very pleasing. For me, what areas do you think you need to improve on most before your next game and do you think you can afford any more draws? Do you pretty much have to try and win every game from there now? Yeah, I think we go in every game wanting to win, that's very important. The circulation of the ball can be a little bit better even so that we had 49% of possession so it was pretty even that way. At times we could have been a little bit more ruthless in and around the box and also in terms of transition from having the ball to without the ball, we look vulnerable at times, that's in our organisation and we were excellent at that before the break, it's something that we'll be discussing. JP, just on the captain, Mitch, I thought it was fitting that he played the cross for the equaliser because he's not like characters, but he led by example, he was in everything and even in the park when you guys were on top, you kept driving his along, do you agree with that? Yeah, look, Mitch does the best he can, I mean physically at times he does too much at times, but he gives us energy and he's always honest in his game. You can't question his desire to play football and to do his best and that's why he's a captain and people will feed off that. He obviously had an assist, the goal that Coxie scored, so there are the rewards you get when you work hard.


So, up to this point, we've read a few different comics, right, and what I figure we do now is hit up a little bit of humor, and this is the Adventures of Barry Wynne, Wynne Boy Genius, and this is probably the funniest comic I've read for at least, at least 10 to 15 years. I was, I just lucked out I came across it, and I was actually looking, went to a local comic shop, and they had a lot of trade paperbacks on sale for two bucks, and it had a combination, it compiled the first, I believe, two mini-series, the two sets of Barry Wynne, and I read it and I just couldn't stop laughing. It was absolutely magnificent. So I went on eBay and I ended up buying all the Barry Wynne floppies, the singles that have been put out, and there's a few of them, there's four different sets. I think there's four different sets anyway. There's Barry Wynne, the first three issues, okay, and they're cheap, they're way less than cover price you can buy these for. And this is actually the first appearance of Barry Wynne, and I personally can't believe that this book is not more sought after because it's absolutely amazing. This is Barry Wynne, Boy Genius, the second set. So it's a three issue again, and then there's Barry Wynne, Monkey Tales, and this is a six issue set, so I guess there's just three sets of this. What we're going to do though, we're just going to read issue number one, okay. The first part of it anyway, I don't know, I can't remember if the whole thing is one set or one story or there's multiple stories, but it's absolutely hilarious, and Barry Wynne, the second one is actually extremely good as well, they're all very good. So what we're going to do is put these aside, and these are the three issues. The first mini series of Barry Wynne, one, two, three, and this is the first appearance, and they came out in 1999 from Image Comics, and the cover price for this was in 1999, 295 US 440 Canadian, which is extremely expensive if you consider 1999 prices, right? So wow, very expensive, which you can pick up right now, very cheap, very cheap. I'm pretty sure for a limited time though, and this is a comic put together by Jud Wynnek, and it's his creation, and he's done some write up explaining who this character is, and it's supposed to be representation or sort of a mock-up of one of his childhood friends or something like this anyway. So what we're going to do, I'm going to crack this open, so I guess this came out in March 1999. As far as grade goes, this is at least, you know, an 8.5, 8.5 at least, it's got some dents and stuff, not dents, but just stress marks and little, no nicks, there's nothing missing, just stress on there. Savage Dragon, Savage Dragon from Image Comics, very good read, Larson did fantastic with it, okay, and I think it's still going, Savage Dragon. So who's one of the few Image creators that stuck with his guns and kept on producing, but this reading is about Barry Wynne, boy genius. So let's take a look, but by Jud Wynnek, okay, dedicated to the real Barry Wynne, my closest friend since childhood, he's not a genius, but he does curse a lot, love you big guy. Cover color by Russ Wooden, art by Jud Wynnek, the adventures of Barry Wynne, boy genius number one, March 1999, first printing Image Comics, publish, let me just keep some going. Image Comics, I guess they're based in California, printed in Canada, a lot of comic books get printed in Canada, or they used to anyway, so let's take a look. This cracks me up knowing what the story is. I do recommend if you like the stuff, go out and buy it because this issue is not going to do it for you, this is just a teaser. You will want to read the rest, okay, so let's take a look. I should probably start at the beginning, I was born a genius, Jesus is cold out here, the eyes of the doctor and the nurse, well I was smart even before birth, and I'm not talking about talking a little smart, I mean way smart, self-awareness and the womb smart, whoa, is this my dick, so this is for mature readers, there is swearing in it, there is no sex, it doesn't say for mature readers, so I'm assuming this is okay to read. So for my own safety, it's seen prudent to keep my vast intellect a secret, goo, I swear it sounds sarcastic when he says that, prior to attaining the proper motor functions to begin my experiments, I endured the level of frustration that I thought would break me.