Thanks for the replies! > I'm not too concerned about breaking API, we _could_ make the next one a > version 2 with a version 2 API, a clean break from version 1
My main point in preserving the compatibiliy is to be sure that the ui will work as expected. This will also limit the scope of the changes. > Whichever framework we pick, I would prefer if we could auto-generate the > JSON/GraphQL API from the source. +1 for automating as much as possible, probably I would lean to first do the JSON as it is now and the consider adding GraphQL. If there is no objections to merging scanners with server I will do this as a first step. Here is a Github issue so we can manage all the work: https://github.com/apache/kibble/issues/64 As per the ideas - I created issues to keep it for future reference :) Bests, Tomek On Mon, Oct 19, 2020 at 7:54 PM Sharan Foga <sha...@apache.org> wrote: > > Hi Tomek > > Thanks for the initiative and ideas! > > Anything that makes things simpler or easier is OK with me :-) and > consolidating things seems like a good idea. I am guessing that a lot of the > changes would probably be behind the scenes rather than at the user end - > right? > > On the wishlist - I saw a talk by Myrle at ApacheCon@Home and she had done > some initial work linking contributions to affiliation and I mentioned seeing > if that could be something we could look at including into Kibble. I think we > tried to do it with Meta Pony Factor but dont think it is complete. Anyway > lots of ideas to keep us going! > > Thanks > Sharan > > > On 2020/10/18 14:28:33, Tomasz Urbaszek <turbas...@apache.org> wrote: > > Hello all, > > > > I would like to propose a few things that I think are worth considering: > > > > 1. Merge all three repositories (kibble, kibble-scanners, > > kibble-docker) into one. In this way I think we may simplify > > development, dependency management, and distribution. Our project is > > rather small and increasing places needing management probably won't > > help. > > > > 2. Once we have the API server and scanner in one repo we can make > > Kibble a python package. This will not only simplify installation and > > setup but also may help us create a nice CLI to manage all components > > (setup, server, scanners). By doing this users will be able to run > > something like `kibble server` or `kibble scanners ponymail`. > > > > 3. Rewrite kibble API server to use a framework (for example FastAPI > > which supports OpenAPI specs). This point is probably the hardest one > > to implement as it will require adding tests to preserve compatibility > > with kibble ui. > > > > What do you think? Do you have anything that you would love to see in > > Apache Kibble? :) > > > > Cheers, > > Tomek > > -- Tomasz Urbaszek Polidea | Software Engineer M: +48 505 628 493 E: tomasz.urbas...@polidea.com Unique Tech Check out our projects!
