A simple API for a saner Future: Plone API
Forcada Codinachs, Gil
Gil will give us an overview of the API and the process used to build it. Plone was built on a multi-layered stack with its origins in 1998, which made for a messy amalgamation of components each with its own API. plone.api was created to hide all those details and present a nice, useful, easy and intuitive API on top of them.
 This talk is about a Plon API, a simple API for signer feature. So that's me with the coconut. I'm on GitHub or Twitter. I'm Jill Forkada. I work at the Afritech, a German weekly newspaper. And I'm part of the, I've been around here in Plon community for a while already, six, seven years. And I'm part of the testing team. Before diving into, actually, what's Plon API or so? Just a quick survey just to see what people do know about already. So who knows Plon API or what's Plon API? Okay. So who uses it already? Okay, perfect. So Plon API, it's a Python distribution for Plon, of course. That tries to provide a simple API to interface with Plon to cover roughly the usual 20% of the tasks that any Plon developer needs to or uses on their regular tasks, 80% of the time. So like the regular bulk of interactions with Plon that you need, most of them are covered here in a nice API. Actually, I haven't done much of that, I just talking about it and cheerleading it because it's a great package. So actually, that was done during these sprints some years ago, especially if you happen to meet with Zupo, just congratulate him because that was an amazing idea that they came up with. But especially all the people involved or mainly all the people involved on that, on those two sprints were the main ones behind it. So why they did it? To begin with. So you have seen that Plon already celebrates this year, the 15th anniversary. And the package behind or the application server, Zup, that Plon uses, it's even older. So of course, 15 years ago, there was a cool way to do things. Three years later, there was a new way. Five years later, yet another way. And you end up with 15 ways to get the exact same results, but in different parts. So that's for anyone that's new, that's kind of like a bit of a scary or uncertain, like, okay, I'm trying to get a user this way, but now I'm checking this other addon and is using it in a different way. Is my code right? Is that wrong? Is there any performance benefit of one or the other? Is there, what's, why there's so many ways to do things? On top of that, there's always inconsistencies, like there's some APIs that use username or others use user ID on the year method calls. And at the end, Plon has almost 300 packages, all in all. So if you want to start really learning, so where do you start? What's the basic functionality that I can get from Plon? How to bootstrap your teams to get productive? Oh, you're here. So here's the one. You should be doing the talk, actually. So that was basically the main, like, as I was saying, how do you actually get the Plon side route? Actually, that always happened to me. I never, ever remember what's the actual import that I have to do to just call that method that gets you the Plon side route. I never, ever learned that by hand. Or checking permissions, if you are checking permissions for an object or just for that permission or in a different user, all these, it's just, at least for me, it's just impossible to remember all the APIs that I need to use. So fortunately, a Plon API come to the rescue. So what I was saying before, the goals are, or so far, have been to cover only, really, not everything because then you are just building yet another layer on top of Plon. That's not the idea. The idea of Plon API is not that it's your only one shop for everything. Everything will, the idea is that not everything will be there because there's no really need. And then the APIs will, anyway, will be just so bloated that the point of making it easier for newcomers and making it usable and approachable, then you miss that completely. But really core features that Plon API provides, those are, like, really the ones that you use on a daily basis and that are really time savings. And for that, it provides a clear API methods, you will see in short. Everything is in one place, so you don't have to remember, like, what any of those 300 packages were, okay, so it's permissions. So probably that's access control, but well, but that's maybe the permission is somewhere else and so on. So not everything is in a single place. You can't really, as a fillet was showing us before, it's really important that when you are looking at something to see where actually the code is, where the implementation is. So keeping everything easy and in the same package, it's really easy just to browse the few files, the few Python files and all the methods and see what's actually there, what functionality is bringing. And especially for Plon, that's like a rather obvious, like really something strange, but it's a really nice API, just like, for example, if anyone has used the requests library to do some HTTP request, that's saying that's so nice to do HTTP. If you have to use HTTP or URL, or some URL, two or three, or I mean, they even make three versions of your relip, so that speaks. And Plon API is probably the first and only API so far in Plon that's really Pythonic, that really feels comfortable to type to when you look at the code and you see some Plon API code there, you basically it speaks by itself. You don't really need to put any comments. You don't need to get into the methods to learn what's actually doing, that everything is there. But the, so how did they get there? How they came up with not only the Plon API, but what need to be there and what and how to do it. So they started with, that's probably something crucial for the Plon API project, that they didn't start writing any single line of code. Instead they did document drive and development. So first of all, they said, well, we are using Plon. We know that it's so complex and everyone is telling us that, so what do we want to get? What do we want to document? Let's come up with some descriptions, some ideas of what we would like to have. So we want to be able to get users. We want to get the portal route. We want to manage content. So those will be the building blocks. So they created first the documentation with all the functionality that they would like to have without even writing a single line of code, just dreaming or thinking out loud or writing it down, actually, what they wanted to do. And only after they were happy with that, then they started document drive and development and testing drive and development so that everything was tested. Actually the documentation itself of Plon API, it's testable already. So if you modify the documentation and you make a mistake, tests will fail. So you will know that you have made the mistake on the documentation itself. And even so the path, first making documentation, then making the tests together with the code, that was really like setting the path to really get a good project and a good code base and a good organization of the code. But especially that's supposed to be style drive and development because if you're starting a package that was done by the community, it was not a code drop from a company like, hey, we come up with this, there you go. But instead it was something done by the community. So community is someone from here, from Boston, somebody from New Zealand, somebody from India. So you need to set some style guides. So they come up with a code style guide. They come up with a release code tool. They come up with how to contribute and all of that is on their documentation. And even further, they went even a step further and pushed all of that upstream to the community. So now what started as being the code style guide for the Plon API, now it's the Plon's style guide. Of course, not all the code has been changed. There's an ongoing effort on that and you are most welcome to join that. But it can feel that it's not so much relevant. At the end, you just want the functionality to work. But setting a style guide allows you that whenever somebody comes with you with the laptop, oh, I have a problem and then you see the code. If the patterns are recognizable, then it's far more easier. Just like it's easier for probably most of you to understand any Latin language rather than a Chinese language because you see the patterns, you see the spaces, you see the puntuations, you see the breaking points. Instead, Chinese or Japanese, they don't have spaces in between letters because they don't have the concept of letters either. And that's way more easier for you to understand if you already know other Latin languages. So if you keep a style guide and you enforce it and you follow it, then all the code will feel the same. All the code will be far more easier to change, far more easier to adapt, far more easier to read, which is at the end what the most time we spend. We spend way more time reading than writing code. So just some quick examples and that's easier to remember. If I want to get, so I mean, that's, I cannot even ask you what's actually that doing. It's already telling you. It's the API to get, you get the portal, the BlonSite portal. That's it. It's easy to remember. It's easy to get whatever you spot that inside any code. You know what's that doing instead of all those random imports and so on. If you want to see if Ava can build a portal, then that's all you have to do. Check the hash permission on the user. And still, for example, here, instead of creating a variable to get the portal and then assigning it on the object you can already do, or it feels natural to use that call here because everything it's, so it's not so, as it's not anymore so much complex to get the portal, you can embed it inside other function calls without actually making it that bloat and all things that intricate. That's something that I love from Blon API, the copy one, because if you actually look at the implementation of content copy, you will see that it's just madness. What you have to do, you have to get the, you have to copy the, or you have to copy the object and you get the clipboard and then you have to base that clipboard somewhere. It's just so much verbose that you miss the point that you are just copying and that's the key here. You just see, well, it's three lines of code, but it's a single method call that does the copying. You don't have to, like, you don't have to go all around with the clipboard and then maybe the clip you have to pass it around and then you way more simpler where more say it gets you done and be with it and deal with the things that you, that do matter the most. But there's, I mean, with Blon API, it's just like a can dist or everything, it's good and everything, it's, everything, it's good. Everything, it's nice and there's always, when you start with good things, then just new good things come. And I'm not sure if any one of you has been looking at the pull requests sent to Blon API. No, sorry, that's, that's later. So yeah, so good thing, good things that comes with Blon API. I'm actually, I did, I did that by myself, I, at some point, I, I started moving all my code to use Blon API whenever I could. So that's why actually I wrote this flake eight Blon API plugin. So if you, if you use a flake eight or Blon recipe code analysis and other package that runs flake eight as well. And this will give you hints that you are using a method call somewhere that could be changed to Blon API. So, so reducing, reducing the amount of packages that you depend on first and cleaning and making your code far more readable. And I was, I was doing that at, at work, like every now and then spending some, some, some minutes, some hours, changing that and the code afterward, just looking the before and after it's just like so much refreshing, so much clean. And especially if you have, if you don't have to look for yourself at all of that, but instead you use, you rely on flake eight to, to report for that then it's, you just need to really know what have to be changed or you already know where to go to, to change things. But then, and then as you use Blon API and the API, it's so nice then if you have your, your spaghetti code thrown there, you start seeing like those little gems here and there and then it gives you the, the, it empowers you, it makes you feel bad for your code. So you want to have a, a say no, a nicer API, just like a Blon API. So it's not just about replacing the code, but also actually making your code even better. And just that's like a perfect example. Or if you ever need, if you ever need a reference to look at how to do things or so, Blon, Blon API, it's the, it's a perfect, it's a perfect package to look for how to do everything. All the best practices are encoded there. And that's what I got before a bit ahead. And those are pull request numbers and done by completely different persons, one or one of them even needs by me, certainly not done by the, by the creator of Blon API. That's, that's the, that's the great thing. And all of them have a, I mean, I just grabbed the last few ones. But all of them have these, these, all of them do change these four files. They add a change log entry, they modify and expand the documentation explaining what the new functionality that they are being, uh, is about. They do add tests. And finally, of course, they do add the, the, the, the implementation. And if you look at the average pull requests in Blon, now, because we have something to enforce it, but they do add, uh, or people do add the change log and of course the code. But nearly nobody is adding, uh, the documentation and most, but not always people is adding tests. But the nice thing with Blon API is that you see that everything is there. The doc strings are there. All the, all the, all the, all the surrounding code is done in a way that you feel, um, obligated or you feel the need to not, uh, to keep it as, um, as nice and as clean as it is. So just because it was done in a nice way and in, and it was consistently done in, in a specific style guide and everything, you see that all the code done by totally completely different persons and at different times in the year and for some different years, but still all of them follow the same rules, which means that any person, um, which means that everyone to understand what are the ways that, um, Blon API wants to things to have so things ca, uh, are kept. Um, or, or so the, the quality, the standards quality is as high as it is. It's not like it started, uh, started really nice because he made it so nice, but then people just don't care and just, just, yeah, yeah, I throw my, my patch here and I just run for it because I don't have more time, but instead people do take the time. Um, and you've actually feel that you can actually point them, Hey, you forgot the documentation. Please do that because everyone else did that. So in a way for the next one that comes afterwards, the documentation is up to date. First test coverage and, um, and the functionality is there with the doc strings and the change locks and everything. Um, so, um, Blon API, um, so you can find, um, of course it's released on, uh, on Piper, the code, it's on GitHub. Um, I was wondering if to put it or not on the, on the slides, but, um, uh, like all the, all the API, um, methods that are available, but the documentation, it's really nice and it's already integrated into the docsplon.org. Um, so just, uh, go there. It's linked from Piper so you can easily go there. It's tested at every change on Travis and of course also, um, it checks the cover, uh, the coverage on Cobrill's IO so that everything it's, it's, um, uh, we cut, we can see that if there's any, um, uh, if it lowers or not. Um, again, best practices, best practices and more best practices. Um, future, of course, um, there's like, for example, there's one that I'm missing a lot lately that I'm usually always trying to get the portal URL. So if anyone feels like, um, getting the portal URL, why not, uh, that feels like a standard 20, 80% rule, um, run upgrades. Uh, I'm, I'm obsessed with running, making a greater steps for everything. So that's something that maybe that's just more for me than for anyone. And basically, um, PLON API now it's in version one point five. So it's already had already five minor releases after the, the fierce one. So it's basically rock solid stable. There's of course a few bucks here there, um, a new API proposals that are on PI on GitHub. But yes. Yeah. Right. That's code for the, the, the, the, the, the, the, the, the, the, the, the, the, the, the right, that's code review things. Um, so, so yeah. Um, if you ever want to start looking at any PLON package, please be that, um, PLON API, that would be, um, like you can see like all the best practices and then go to the dark corners of PLON. Um, but at least so that you get a bit of a piece of mind that there's some sane, uh, code inside PLON still. Um, so if anyone is up for sprinting, I will probably be doing something testing related, but I will be glad to, to help anyone on that. Um, and I'm done. Thanks for listening. And I think we have time for questions probably. Still models in, in on the, in on the art. Yes. Yeah like fully back and I'll let go because I mean I think 4 grading is already satisfied like, so, you know like you could really use a lot of abstraction, but now I'm looking I'm looking back at like, I need to modify some more phone behavior. Then I'll use phone API. Is there a plan to be back for that? So it uses that? That's like, you know this 2020 ongoing discussion about the future and so on. More or less in a smaller scale, also happened with phone API. Using a plan API in core means that plan API should not use core because then you have circular dependencies. So for me, yes, I would totally love to be able to use this Flake8 plan API and just replace everything because it will be so much readable. But then that means that either we get all the dependencies that plan API relies on and we put everything there. So it's like a massive amount of, well, we could create a module like don't look here and then put all the dependencies there. But that's probably not sustainable in the long run. But yeah, definitely, I mean, I see your point and I share your desire. The technical part, it's a bit more complex, but of course you can bring that up in communityplan.org anytime and see how the below file goes. It would be really, really, really nice. What's the current state of the issue check or a lot of issues open and waiting for requests? If you know from the top of your head. Pool requests open, I think that there's one or two and there's an issues, there's a handful of them, sure. Some are like, let's add this new thing, but nobody step up to do it. And there's a few bugs indeed. And there's the still ongoing discussion with user ID, username, and probably that will require a 2.0 version just to make sure that we don't break semantic versioning. Again, something that was introduced by Plon API, best practice, use semantic versioning. But not that activity, it's quite low. So like really people, I guess, that everyone is using it and being happy with it. And yeah, but there were ideas of adding way new modules and so on, but now maybe things are moving more to the REST API, I think. I mean, personally, this one that I was saying before, this get portal URL or portal get URL. And that's probably one of the few things that for myself I would like to have there, but I don't find myself wanting much, much more there so far, not sure if anyone that's using it if they do. But of course, just create an issue on GitHub, have Plon API, we can discuss, and add the functionality if needed. More questions? Yeah. Always try to consider through the web stuff. Plon API is actually really helpful. And when you are doing through the web stuff, you would like to benefit. Do you consider it as a security issue? Because if you consider that any through the web with whatever battles you find, whether it is gonna anyway apply the security and permission of the computer, do you think it is a security issue or not? To use Plon API through the web, you mean? Yeah. Well, there's definitely a lot of methods on it that are totally secure, like getting the portal route, for example, or checking permissions, things. Creating content, maybe that's, well, I mean, at the end, even if it's from restricted Python, you will get the security checks. So far, I'm not on the security team, so I cannot really say that, but I would say that maybe it is, or especially, or if you know what you are doing, probably yes, like really making it completely open. I'm not so sure, especially with the problem with the doc strings, that everything is public then because all of them do have a doc string. So that would be probably a security concern for our great security team. But definitely that could be, or at least even a subset of it could be quite listed. That's definitely, I have no idea how to whitelist things to be enabled through the web, but definitely there's material that could be and will make, of course, the code through the web in rapid or so, way more nicer, sure. Any more questions?
 This talk is about a Plon API, a simple API for signer feature.  So that's me with the coconut.  I'm on GitHub or Twitter.  I'm Jill Forkada.  I work at the Afritech, a German weekly newspaper.  And I'm part of the, I've been around here in Plon community for a while already, six,  seven years.  And I'm part of the testing team.  Before diving into, actually, what's Plon API or so?  Just a quick survey just to see what people do know about already.  So who knows Plon API or what's Plon API?  Okay.  So who uses it already?  Okay, perfect.  So Plon API, it's a Python distribution for Plon, of course.  That tries to provide a simple API to interface with Plon to cover roughly the usual 20% of  the tasks that any Plon developer needs to or uses on their regular tasks, 80% of the  time.  So like the regular bulk of interactions with Plon that you need, most of them are covered  here in a nice API.  Actually, I haven't done much of that, I just talking about it and cheerleading it because  it's a great package.  So actually, that was done during these sprints some years ago, especially if you happen to  meet with Zupo, just congratulate him because that was an amazing idea that they came up  with.  But especially all the people involved or mainly all the people involved on that, on  those two sprints were the main ones behind it.  So why they did it?  To begin with.  So you have seen that Plon already celebrates this year, the 15th anniversary.  And the package behind or the application server, Zup, that Plon uses, it's even older.  So of course, 15 years ago, there was a cool way to do things.  Three years later, there was a new way.  Five years later, yet another way.  And you end up with 15 ways to get the exact same results, but in different parts.  So that's for anyone that's new, that's kind of like a bit of a scary or uncertain, like,  okay, I'm trying to get a user this way, but now I'm checking this other addon and is using  it in a different way.  Is my code right?  Is that wrong?  Is there any performance benefit of one or the other?  Is there, what's, why there's so many ways to do things?  On top of that, there's always inconsistencies, like there's some APIs that use username or  others use user ID on the year method calls.  And at the end, Plon has almost 300 packages, all in all.  So if you want to start really learning, so where do you start?  What's the basic functionality that I can get from Plon?  How to bootstrap your teams to get productive?  Oh, you're here.  So here's the one.  You should be doing the talk, actually.  So that was basically the main, like, as I was saying, how do you actually get the Plon  side route?  Actually, that always happened to me.  I never, ever remember what's the actual import that I have to do to just call that method  that gets you the Plon side route.  I never, ever learned that by hand.  Or checking permissions, if you are checking permissions for an object or just for that  permission or in a different user, all these, it's just, at least for me, it's just impossible  to remember all the APIs that I need to use.  So fortunately, a Plon API come to the rescue.  So what I was saying before, the goals are, or so far, have been to cover only, really,  not everything because then you are just building yet another layer on top of Plon.  That's not the idea.  The idea of Plon API is not that it's your only one shop for everything.  Everything will, the idea is that not everything will be there because there's no really need.  And then the APIs will, anyway, will be just so bloated that the point of making it easier  for newcomers and making it usable and approachable, then you miss that completely.  But really core features that Plon API provides, those are, like, really the ones that you  use on a daily basis and that are really time savings.  And for that, it provides a clear API methods, you will see in short.  Everything is in one place, so you don't have to remember, like, what any of those 300 packages  were, okay, so it's permissions.  So probably that's access control, but well, but that's maybe the permission is somewhere  else and so on.  So not everything is in a single place.  You can't really, as a fillet was showing us before, it's really important that when  you are looking at something to see where actually the code is, where the implementation  is.  So keeping everything easy and in the same package, it's really easy just to browse the  few files, the few Python files and all the methods and see what's actually there, what  functionality is bringing.  And especially for Plon, that's like a rather obvious, like really something strange, but  it's a really nice API, just like, for example, if anyone has used the requests library to  do some HTTP request, that's saying that's so nice to do HTTP.  If you have to use HTTP or URL, or some URL, two or three, or I mean, they even make three  versions of your relip, so that speaks.  And Plon API is probably the first and only API so far in Plon that's really Pythonic,  that really feels comfortable to type to when you look at the code and you see some Plon  API code there, you basically it speaks by itself.  You don't really need to put any comments.  You don't need to get into the methods to learn what's actually doing, that everything  is there.  But the, so how did they get there?  How they came up with not only the Plon API, but what need to be there and what and how  to do it.  So they started with, that's probably something crucial for the Plon API project, that they  didn't start writing any single line of code.  Instead they did document drive and development.  So first of all, they said, well, we are using Plon.  We know that it's so complex and everyone is telling us that, so what do we want to  get?  What do we want to document?  Let's come up with some descriptions, some ideas of what we would like to have.  So we want to be able to get users.  We want to get the portal route.  We want to manage content.  So those will be the building blocks.  So they created first the documentation with all the functionality that they would like  to have without even writing a single line of code, just dreaming or thinking out loud  or writing it down, actually, what they wanted to do.  And only after they were happy with that, then they started document drive and development  and testing drive and development so that everything was tested.  Actually the documentation itself of Plon API, it's testable already.  So if you modify the documentation and you make a mistake, tests will fail.  So you will know that you have made the mistake on the documentation itself.  And even so the path, first making documentation, then making the tests together with the code,  that was really like setting the path to really get a good project and a good code base and  a good organization of the code.  But especially that's supposed to be style drive and development because if you're starting  a package that was done by the community, it was not a code drop from a company like,  hey, we come up with this, there you go.  But instead it was something done by the community.  So community is someone from here, from Boston, somebody from New Zealand, somebody from India.  So you need to set some style guides.  So they come up with a code style guide.  They come up with a release code tool.  They come up with how to contribute and all of that is on their documentation.  And even further, they went even a step further and pushed all of that upstream to the community.  So now what started as being the code style guide for the Plon API, now it's the Plon's  style guide.  Of course, not all the code has been changed.  There's an ongoing effort on that and you are most welcome to join that.  But it can feel that it's not so much relevant.  At the end, you just want the functionality to work.  But setting a style guide allows you that whenever somebody comes with you with the  laptop, oh, I have a problem and then you see the code.  If the patterns are recognizable, then it's far more easier.  Just like it's easier for probably most of you to understand any Latin language rather  than a Chinese language because you see the patterns, you see the spaces, you see the  puntuations, you see the breaking points.  Instead, Chinese or Japanese, they don't have spaces in between letters because they  don't have the concept of letters either.  And that's way more easier for you to understand if you already know other Latin languages.  So if you keep a style guide and you enforce it and you follow it, then all the code will  feel the same.  All the code will be far more easier to change, far more easier to adapt, far more easier  to read, which is at the end what the most time we spend.  We spend way more time reading than writing code.  So just some quick examples and that's easier to remember.  If I want to get, so I mean, that's, I cannot even ask you what's actually that doing.  It's already telling you.  It's the API to get, you get the portal, the BlonSite portal.  That's it.  It's easy to remember.  It's easy to get whatever you spot that inside any code.  You know what's that doing instead of all those random imports and so on.  If you want to see if Ava can build a portal, then that's all you have to do.  Check the hash permission on the user.  And still, for example, here, instead of creating a variable to get the portal and then assigning  it on the object you can already do, or it feels natural to use that call here because  everything it's, so it's not so, as it's not anymore so much complex to get the portal,  you can embed it inside other function calls without actually making it that bloat and  all things that intricate.  That's something that I love from Blon API, the copy one, because if you actually look  at the implementation of content copy, you will see that it's just madness.  What you have to do, you have to get the, you have to copy the, or you have to copy  the object and you get the clipboard and then you have to base that clipboard somewhere.  It's just so much verbose that you miss the point that you are just copying and that's  the key here.  You just see, well, it's three lines of code, but it's a single method call that does the  copying.  You don't have to, like, you don't have to go all around with the clipboard and then  maybe the clip you have to pass it around and then you way more simpler where more say  it gets you done and be with it and deal with the things that you, that do matter the most.  But there's, I mean, with Blon API, it's just like a can dist or everything, it's good  and everything, it's, everything, it's good.  Everything, it's nice and there's always, when you start with good things, then just  new good things come.  And I'm not sure if any one of you has been looking at the pull requests sent to Blon  API.  No, sorry, that's, that's later.  So yeah, so good thing, good things that comes with Blon API.  I'm actually, I did, I did that by myself, I, at some point, I, I started moving all  my code to use Blon API whenever I could.  So that's why actually I wrote this flake eight Blon API plugin.  So if you, if you use a flake eight or Blon recipe code analysis and other package that  runs flake eight as well.  And this will give you hints that you are using a method call somewhere that could be  changed to Blon API.  So, so reducing, reducing the amount of packages that you depend on first and cleaning and  making your code far more readable.  And I was, I was doing that at, at work, like every now and then spending some, some, some  minutes, some hours, changing that and the code afterward, just looking the before and  after it's just like so much refreshing, so much clean.  And especially if you have, if you don't have to look for yourself at all of that, but instead  you use, you rely on flake eight to, to report for that then it's, you just need to really  know what have to be changed or you already know where to go to, to change things.  But then, and then as you use Blon API and the API, it's so nice then if you have your,  your spaghetti code thrown there, you start seeing like those little gems here and there  and then it gives you the, the, it empowers you, it makes you feel bad for your code.  So you want to have a, a say no, a nicer API, just like a Blon API.  So it's not just about replacing the code, but also actually making your code even better.  And just that's like a perfect example.  Or if you ever need, if you ever need a reference to look at how to do things or so, Blon, Blon  API, it's the, it's a perfect, it's a perfect package to look for how to do everything.  All the best practices are encoded there.  And that's what I got before a bit ahead.  And those are pull request numbers and done by completely different persons, one or one  of them even needs by me, certainly not done by the, by the creator of Blon API.  That's, that's the, that's the great thing.  And all of them have a, I mean, I just grabbed the last few ones.  But all of them have these, these, all of them do change these four files.  They add a change log entry, they modify and expand the documentation explaining what the  new functionality that they are being, uh, is about.  They do add tests.  And finally, of course, they do add the, the, the, the implementation.  And if you look at the average pull requests in Blon, now, because we have something to  enforce it, but they do add, uh, or people do add the change log and of course the code.  But nearly nobody is adding, uh, the documentation and most, but not always people is adding  tests.  But the nice thing with Blon API is that you see that everything is there.  The doc strings are there.  All the, all the, all the, all the surrounding code is done in a way that you feel, um, obligated  or you feel the need to not, uh, to keep it as, um, as nice and as clean as it is.  So just because it was done in a nice way and in, and it was consistently done in, in  a specific style guide and everything, you see that all the code done by totally completely  different persons and at different times in the year and for some different years, but  still all of them follow the same rules, which means that any person, um, which means that  everyone to understand what are the ways that, um, Blon API wants to things to have so things  ca, uh, are kept.  Um, or, or so the, the quality, the standards quality is as high as it is.  It's not like it started, uh, started really nice because he made it so nice, but then  people just don't care and just, just, yeah, yeah, I throw my, my patch here and I just  run for it because I don't have more time, but instead people do take the time.  Um, and you've actually feel that you can actually point them, Hey, you forgot the documentation.  Please do that because everyone else did that.  So in a way for the next one that comes afterwards, the documentation is up to date.  First test coverage and, um, and the functionality is there with the doc strings and the change  locks and everything.  Um, so, um, Blon API, um, so you can find, um, of course it's released on, uh, on Piper,  the code, it's on GitHub.  Um, I was wondering if to put it or not on the, on the slides, but, um, uh, like all  the, all the API, um, methods that are available, but the documentation, it's really nice and  it's already integrated into the docsplon.org.  Um, so just, uh, go there.  It's linked from Piper so you can easily go there.  It's tested at every change on Travis and of course also, um, it checks the cover, uh,  the coverage on Cobrill's IO so that everything it's, it's, um, uh, we cut, we can see that  if there's any, um, uh, if it lowers or not.  Um, again, best practices, best practices and more best practices.  Um, future, of course, um, there's like, for example, there's one that I'm missing a lot  lately that I'm usually always trying to get the portal URL.  So if anyone feels like, um, getting the portal URL, why not, uh, that feels like a standard  20, 80% rule, um, run upgrades.  Uh, I'm, I'm obsessed with running, making a greater steps for everything.  So that's something that maybe that's just more for me than for anyone.  And basically, um, PLON API now it's in version one point five.  So it's already had already five minor releases after the, the fierce one.  So it's basically rock solid stable.  There's of course a few bucks here there, um, a new API proposals that are on PI on GitHub.  But yes.  Yeah.  Right.  That's code for the, the, the, the, the, the, the, the, the, the, the, the, the, the, the  right, that's code review things.  Um, so, so yeah.  Um, if you ever want to start looking at any PLON package, please be that, um, PLON API,  that would be, um, like you can see like all the best practices and then go to the dark  corners of PLON.  Um, but at least so that you get a bit of a piece of mind that there's some sane, uh,  code inside PLON still.  Um, so if anyone is up for sprinting, I will probably be doing something testing related,  but I will be glad to, to help anyone on that.  Um, and I'm done.  Thanks for listening.  And I think we have time for questions probably.  Still models in, in on the, in on the art.  Yes.  Yeah like fully back and I'll let go because I mean I think 4 grading is already satisfied  like, so, you know like you could really use a lot of abstraction, but now I'm looking  I'm looking back at like, I need to modify some more  phone behavior.  Then I'll use phone API.  Is there a plan to be back for that?  So it uses that?  That's like, you know this 2020 ongoing discussion  about the future and so on.  More or less in a smaller scale,  also happened with phone API.  Using a plan API in core means that plan API  should not use core because then you have  circular dependencies.  So for me, yes, I would totally love to be able  to use this Flake8 plan API and just replace everything  because it will be so much readable.  But then that means that either we get all the dependencies  that plan API relies on and we put everything there.  So it's like a massive amount of, well,  we could create a module like don't look here  and then put all the dependencies there.  But that's probably not sustainable in the long run.  But yeah, definitely, I mean, I see your point  and I share your desire.  The technical part, it's a bit more complex,  but of course you can bring that up in communityplan.org  anytime and see how the below file goes.  It would be really, really, really nice.  What's the current state of the issue check  or a lot of issues open and waiting for requests?  If you know from the top of your head.  Pool requests open, I think that there's one or two  and there's an issues, there's a handful of them, sure.  Some are like, let's add this new thing,  but nobody step up to do it.  And there's a few bugs indeed.  And there's the still ongoing discussion  with user ID, username, and probably that will require  a 2.0 version just to make sure that we don't break  semantic versioning.  Again, something that was introduced by Plon API,  best practice, use semantic versioning.  But not that activity, it's quite low.  So like really people, I guess,  that everyone is using it and being happy with it.  And yeah, but there were ideas of adding way new modules  and so on, but now maybe things are moving more  to the REST API, I think.  I mean, personally, this one that I was saying before,  this get portal URL or portal get URL.  And that's probably one of the few things  that for myself I would like to have there,  but I don't find myself wanting much, much more there  so far, not sure if anyone that's using it if they do.  But of course, just create an issue on GitHub,  have Plon API, we can discuss, and add the functionality  if needed.  More questions?  Yeah.  Always try to consider through the web stuff.  Plon API is actually really helpful.  And when you are doing through the web stuff,  you would like to benefit.  Do you consider it as a security issue?  Because if you consider that any through the web  with whatever battles you find,  whether it is gonna anyway apply the security  and permission of the computer,  do you think it is a security issue or not?  To use Plon API through the web, you mean?  Yeah.  Well, there's definitely a lot of methods on it  that are totally secure, like getting the portal route,  for example, or checking permissions, things.  Creating content, maybe that's, well, I mean,  at the end, even if it's from restricted Python,  you will get the security checks.  So far, I'm not on the security team,  so I cannot really say that, but I would say that maybe it is,  or especially, or if you know what you are doing,  probably yes, like really making it completely open.  I'm not so sure, especially with the problem  with the doc strings, that everything is public then  because all of them do have a doc string.  So that would be probably a security concern  for our great security team.  But definitely that could be, or at least even a subset  of it could be quite listed.  That's definitely, I have no idea how to whitelist things  to be enabled through the web, but definitely there's material  that could be and will make, of course,  the code through the web in rapid or so,  way more nicer, sure.  Any more questions?
Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_0_71.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_72_167.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_168_251.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_252_563.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_564_863.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_864_911.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_912_1019.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1020_1115.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1116_1247.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1248_1319.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1320_1571.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1572_1619.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1620_1679.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1680_1727.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1728_1775.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_1776_2567.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_2568_3047.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_3048_3767.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_3768_5951.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_5952_7271.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_7272_7835.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_7836_9239.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_9240_12311.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_12312_15947.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_15948_21731.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_21732_24311.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_24312_26843.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_26844_27851.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_27852_28823.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_28824_30959.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_30960_31127.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_31128_32591.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_32592_36923.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_36924_37019.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_37020_42263.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_42264_42503.png Day_1__Plone_API__by_Gil_Forcada_Codinachs_q8xKeJ_NJuw_42504_46533.png
This talk is about a Plon API, a simple API for signer feature. So that's me with the coconut. I'm on GitHub or Twitter. I'm Jill Forkada. I work at the Afritech, a German weekly newspaper. And I'm part of the, I've been around here in Plon community for a while already, six, seven years. And I'm part of the testing team. Before diving into, actually, what's Plon API or so? Just a quick survey just to see what people do know about already. So who knows Plon API or what's Plon API? Okay. So who uses it already? Okay, perfect. So Plon API, it's a Python distribution for Plon, of course. That tries to provide a simple API to interface with Plon to cover roughly the usual 20% of the tasks that any Plon developer needs to or uses on their regular tasks, 80% of the time. So like the regular bulk of interactions with Plon that you need, most of them are covered here in a nice API. Actually, I haven't done much of that, I just talking about it and cheerleading it because it's a great package. So actually, that was done during these sprints some years ago, especially if you happen to meet with Zupo, just congratulate him because that was an amazing idea that they came up with. But especially all the people involved or mainly all the people involved on that, on those two sprints were the main ones behind it. So why they did it? To begin with. So you have seen that Plon already celebrates this year, the 15th anniversary. And the package behind or the application server, Zup, that Plon uses, it's even older. So of course, 15 years ago, there was a cool way to do things. Three years later, there was a new way. Five years later, yet another way. And you end up with 15 ways to get the exact same results, but in different parts. So that's for anyone that's new, that's kind of like a bit of a scary or uncertain, like, okay, I'm trying to get a user this way, but now I'm checking this other addon and is using it in a different way. Is my code right? Is that wrong? Is there any performance benefit of one or the other? Is there, what's, why there's so many ways to do things? On top of that, there's always inconsistencies, like there's some APIs that use username or others use user ID on the year method calls. And at the end, Plon has almost 300 packages, all in all. So if you want to start really learning, so where do you start? What's the basic functionality that I can get from Plon? How to bootstrap your teams to get productive? Oh, you're here. So here's the one. You should be doing the talk, actually. So that was basically the main, like, as I was saying, how do you actually get the Plon side route? Actually, that always happened to me. I never, ever remember what's the actual import that I have to do to just call that method that gets you the Plon side route. I never, ever learned that by hand. Or checking permissions, if you are checking permissions for an object or just for that permission or in a different user, all these, it's just, at least for me, it's just impossible to remember all the APIs that I need to use. So fortunately, a Plon API come to the rescue. So what I was saying before, the goals are, or so far, have been to cover only, really, not everything because then you are just building yet another layer on top of Plon. That's not the idea. The idea of Plon API is not that it's your only one shop for everything. Everything will, the idea is that not everything will be there because there's no really need. And then the APIs will, anyway, will be just so bloated that the point of making it easier for newcomers and making it usable and approachable, then you miss that completely. But really core features that Plon API provides, those are, like, really the ones that you use on a daily basis and that are really time savings. And for that, it provides a clear API methods, you will see in short. Everything is in one place, so you don't have to remember, like, what any of those 300 packages were, okay, so it's permissions. So probably that's access control, but well, but that's maybe the permission is somewhere else and so on. So not everything is in a single place. You can't really, as a fillet was showing us before, it's really important that when you are looking at something to see where actually the code is, where the implementation is. So keeping everything easy and in the same package, it's really easy just to browse the few files, the few Python files and all the methods and see what's actually there, what functionality is bringing. And especially for Plon, that's like a rather obvious, like really something strange, but it's a really nice API, just like, for example, if anyone has used the requests library to do some HTTP request, that's saying that's so nice to do HTTP. If you have to use HTTP or URL, or some URL, two or three, or I mean, they even make three versions of your relip, so that speaks. And Plon API is probably the first and only API so far in Plon that's really Pythonic, that really feels comfortable to type to when you look at the code and you see some Plon API code there, you basically it speaks by itself. You don't really need to put any comments. You don't need to get into the methods to learn what's actually doing, that everything is there. But the, so how did they get there? How they came up with not only the Plon API, but what need to be there and what and how to do it. So they started with, that's probably something crucial for the Plon API project, that they didn't start writing any single line of code. Instead they did document drive and development. So first of all, they said, well, we are using Plon. We know that it's so complex and everyone is telling us that, so what do we want to get? What do we want to document? Let's come up with some descriptions, some ideas of what we would like to have. So we want to be able to get users. We want to get the portal route. We want to manage content. So those will be the building blocks. So they created first the documentation with all the functionality that they would like to have without even writing a single line of code, just dreaming or thinking out loud or writing it down, actually, what they wanted to do. And only after they were happy with that, then they started document drive and development and testing drive and development so that everything was tested. Actually the documentation itself of Plon API, it's testable already. So if you modify the documentation and you make a mistake, tests will fail. So you will know that you have made the mistake on the documentation itself. And even so the path, first making documentation, then making the tests together with the code, that was really like setting the path to really get a good project and a good code base and a good organization of the code. But especially that's supposed to be style drive and development because if you're starting a package that was done by the community, it was not a code drop from a company like, hey, we come up with this, there you go. But instead it was something done by the community. So community is someone from here, from Boston, somebody from New Zealand, somebody from India. So you need to set some style guides. So they come up with a code style guide. They come up with a release code tool. They come up with how to contribute and all of that is on their documentation. And even further, they went even a step further and pushed all of that upstream to the community. So now what started as being the code style guide for the Plon API, now it's the Plon's style guide. Of course, not all the code has been changed. There's an ongoing effort on that and you are most welcome to join that. But it can feel that it's not so much relevant. At the end, you just want the functionality to work. But setting a style guide allows you that whenever somebody comes with you with the laptop, oh, I have a problem and then you see the code. If the patterns are recognizable, then it's far more easier. Just like it's easier for probably most of you to understand any Latin language rather than a Chinese language because you see the patterns, you see the spaces, you see the puntuations, you see the breaking points. Instead, Chinese or Japanese, they don't have spaces in between letters because they don't have the concept of letters either. And that's way more easier for you to understand if you already know other Latin languages. So if you keep a style guide and you enforce it and you follow it, then all the code will feel the same. All the code will be far more easier to change, far more easier to adapt, far more easier to read, which is at the end what the most time we spend. We spend way more time reading than writing code. So just some quick examples and that's easier to remember. If I want to get, so I mean, that's, I cannot even ask you what's actually that doing. It's already telling you. It's the API to get, you get the portal, the BlonSite portal. That's it. It's easy to remember. It's easy to get whatever you spot that inside any code. You know what's that doing instead of all those random imports and so on. If you want to see if Ava can build a portal, then that's all you have to do. Check the hash permission on the user. And still, for example, here, instead of creating a variable to get the portal and then assigning it on the object you can already do, or it feels natural to use that call here because everything it's, so it's not so, as it's not anymore so much complex to get the portal, you can embed it inside other function calls without actually making it that bloat and all things that intricate. That's something that I love from Blon API, the copy one, because if you actually look at the implementation of content copy, you will see that it's just madness. What you have to do, you have to get the, you have to copy the, or you have to copy the object and you get the clipboard and then you have to base that clipboard somewhere. It's just so much verbose that you miss the point that you are just copying and that's the key here. You just see, well, it's three lines of code, but it's a single method call that does the copying. You don't have to, like, you don't have to go all around with the clipboard and then maybe the clip you have to pass it around and then you way more simpler where more say it gets you done and be with it and deal with the things that you, that do matter the most. But there's, I mean, with Blon API, it's just like a can dist or everything, it's good and everything, it's, everything, it's good. Everything, it's nice and there's always, when you start with good things, then just new good things come. And I'm not sure if any one of you has been looking at the pull requests sent to Blon API. No, sorry, that's, that's later. So yeah, so good thing, good things that comes with Blon API. I'm actually, I did, I did that by myself, I, at some point, I, I started moving all my code to use Blon API whenever I could. So that's why actually I wrote this flake eight Blon API plugin. So if you, if you use a flake eight or Blon recipe code analysis and other package that runs flake eight as well. And this will give you hints that you are using a method call somewhere that could be changed to Blon API. So, so reducing, reducing the amount of packages that you depend on first and cleaning and making your code far more readable. And I was, I was doing that at, at work, like every now and then spending some, some, some minutes, some hours, changing that and the code afterward, just looking the before and after it's just like so much refreshing, so much clean. And especially if you have, if you don't have to look for yourself at all of that, but instead you use, you rely on flake eight to, to report for that then it's, you just need to really know what have to be changed or you already know where to go to, to change things. But then, and then as you use Blon API and the API, it's so nice then if you have your, your spaghetti code thrown there, you start seeing like those little gems here and there and then it gives you the, the, it empowers you, it makes you feel bad for your code. So you want to have a, a say no, a nicer API, just like a Blon API. So it's not just about replacing the code, but also actually making your code even better. And just that's like a perfect example. Or if you ever need, if you ever need a reference to look at how to do things or so, Blon, Blon API, it's the, it's a perfect, it's a perfect package to look for how to do everything. All the best practices are encoded there. And that's what I got before a bit ahead. And those are pull request numbers and done by completely different persons, one or one of them even needs by me, certainly not done by the, by the creator of Blon API. That's, that's the, that's the great thing. And all of them have a, I mean, I just grabbed the last few ones. But all of them have these, these, all of them do change these four files. They add a change log entry, they modify and expand the documentation explaining what the new functionality that they are being, uh, is about. They do add tests. And finally, of course, they do add the, the, the, the implementation. And if you look at the average pull requests in Blon, now, because we have something to enforce it, but they do add, uh, or people do add the change log and of course the code. But nearly nobody is adding, uh, the documentation and most, but not always people is adding tests. But the nice thing with Blon API is that you see that everything is there. The doc strings are there. All the, all the, all the, all the surrounding code is done in a way that you feel, um, obligated or you feel the need to not, uh, to keep it as, um, as nice and as clean as it is. So just because it was done in a nice way and in, and it was consistently done in, in a specific style guide and everything, you see that all the code done by totally completely different persons and at different times in the year and for some different years, but still all of them follow the same rules, which means that any person, um, which means that everyone to understand what are the ways that, um, Blon API wants to things to have so things ca, uh, are kept. Um, or, or so the, the quality, the standards quality is as high as it is. It's not like it started, uh, started really nice because he made it so nice, but then people just don't care and just, just, yeah, yeah, I throw my, my patch here and I just run for it because I don't have more time, but instead people do take the time. Um, and you've actually feel that you can actually point them, Hey, you forgot the documentation. Please do that because everyone else did that. So in a way for the next one that comes afterwards, the documentation is up to date. First test coverage and, um, and the functionality is there with the doc strings and the change locks and everything. Um, so, um, Blon API, um, so you can find, um, of course it's released on, uh, on Piper, the code, it's on GitHub. Um, I was wondering if to put it or not on the, on the slides, but, um, uh, like all the, all the API, um, methods that are available, but the documentation, it's really nice and it's already integrated into the docsplon.org. Um, so just, uh, go there. It's linked from Piper so you can easily go there. It's tested at every change on Travis and of course also, um, it checks the cover, uh, the coverage on Cobrill's IO so that everything it's, it's, um, uh, we cut, we can see that if there's any, um, uh, if it lowers or not. Um, again, best practices, best practices and more best practices. Um, future, of course, um, there's like, for example, there's one that I'm missing a lot lately that I'm usually always trying to get the portal URL. So if anyone feels like, um, getting the portal URL, why not, uh, that feels like a standard 20, 80% rule, um, run upgrades. Uh, I'm, I'm obsessed with running, making a greater steps for everything. So that's something that maybe that's just more for me than for anyone. And basically, um, PLON API now it's in version one point five. So it's already had already five minor releases after the, the fierce one. So it's basically rock solid stable. There's of course a few bucks here there, um, a new API proposals that are on PI on GitHub. But yes. Yeah. Right. That's code for the, the, the, the, the, the, the, the, the, the, the, the, the, the, the right, that's code review things. Um, so, so yeah. Um, if you ever want to start looking at any PLON package, please be that, um, PLON API, that would be, um, like you can see like all the best practices and then go to the dark corners of PLON. Um, but at least so that you get a bit of a piece of mind that there's some sane, uh, code inside PLON still. Um, so if anyone is up for sprinting, I will probably be doing something testing related, but I will be glad to, to help anyone on that. Um, and I'm done. Thanks for listening. And I think we have time for questions probably. Still models in, in on the, in on the art. Yes. Yeah like fully back and I'll let go because I mean I think 4 grading is already satisfied like, so, you know like you could really use a lot of abstraction, but now I'm looking I'm looking back at like, I need to modify some more phone behavior. Then I'll use phone API. Is there a plan to be back for that? So it uses that? That's like, you know this 2020 ongoing discussion about the future and so on. More or less in a smaller scale, also happened with phone API. Using a plan API in core means that plan API should not use core because then you have circular dependencies. So for me, yes, I would totally love to be able to use this Flake8 plan API and just replace everything because it will be so much readable. But then that means that either we get all the dependencies that plan API relies on and we put everything there. So it's like a massive amount of, well, we could create a module like don't look here and then put all the dependencies there. But that's probably not sustainable in the long run. But yeah, definitely, I mean, I see your point and I share your desire. The technical part, it's a bit more complex, but of course you can bring that up in communityplan.org anytime and see how the below file goes. It would be really, really, really nice. What's the current state of the issue check or a lot of issues open and waiting for requests? If you know from the top of your head. Pool requests open, I think that there's one or two and there's an issues, there's a handful of them, sure. Some are like, let's add this new thing, but nobody step up to do it. And there's a few bugs indeed. And there's the still ongoing discussion with user ID, username, and probably that will require a 2.0 version just to make sure that we don't break semantic versioning. Again, something that was introduced by Plon API, best practice, use semantic versioning. But not that activity, it's quite low. So like really people, I guess, that everyone is using it and being happy with it. And yeah, but there were ideas of adding way new modules and so on, but now maybe things are moving more to the REST API, I think. I mean, personally, this one that I was saying before, this get portal URL or portal get URL. And that's probably one of the few things that for myself I would like to have there, but I don't find myself wanting much, much more there so far, not sure if anyone that's using it if they do. But of course, just create an issue on GitHub, have Plon API, we can discuss, and add the functionality if needed. More questions? Yeah. Always try to consider through the web stuff. Plon API is actually really helpful. And when you are doing through the web stuff, you would like to benefit. Do you consider it as a security issue? Because if you consider that any through the web with whatever battles you find, whether it is gonna anyway apply the security and permission of the computer, do you think it is a security issue or not? To use Plon API through the web, you mean? Yeah. Well, there's definitely a lot of methods on it that are totally secure, like getting the portal route, for example, or checking permissions, things. Creating content, maybe that's, well, I mean, at the end, even if it's from restricted Python, you will get the security checks. So far, I'm not on the security team, so I cannot really say that, but I would say that maybe it is, or especially, or if you know what you are doing, probably yes, like really making it completely open. I'm not so sure, especially with the problem with the doc strings, that everything is public then because all of them do have a doc string. So that would be probably a security concern for our great security team. But definitely that could be, or at least even a subset of it could be quite listed. That's definitely, I have no idea how to whitelist things to be enabled through the web, but definitely there's material that could be and will make, of course, the code through the web in rapid or so, way more nicer, sure. Any more questions?
provide a simple API to interface with Plon to another layer on top of Plon. That's not the everything easy and in the same package, it's what's that doing instead of all those random as well. And this will give you hints that you is. So just because it was done in a nice way and and there's an issues, there's a handful of them,