Kent, Saturday, August 9, 2014, 9:42:18 PM, you wrote:
Thank you for your opinion. I really don't think data processing unit comes first. Communication protocol is already there - it's HTTP, method POST HTTP protocol is already with Python - CURL, WGET A reliable server ready to accept data from portage is all so there - it's Apache web server. What we don't have to start with portage class is just a number of parameters to submit. If you're experienced with portage - help work out parameters you consider useful for server. Example: system_arch : system_name : system_environment: portage_message : portage_tree: package_failed: xorg-1.2.3 /example/ etc. Once the list is ready -> add it reporter to portage -> and the server side data processing unit will appear. On 10 August 2014 04:18, Igor <lanthrus...@gmail.com> wrote: 5. Wait for server-side implementations to appear. They will appear once emerge can report. And once it's clear for the rest that there is seriously going to be a change soon. It really needs to be designed from the server side, not the client side. And defaulting on is a bad default. The reason the server part has to come first is the server side serves as reference implementation of how the communication protocol is to work, and how reports are to be aggregated. The best part here, is the server can also be designed without needing to modify the portage source. The server can be created, and a dummy client can be created that speaks its language and submits "sample" reports of some kind. Once the server is doing what it needs to do as a basic feature set in recording and storing reported data, the dummy client can be enhanced to be an out-of-band too that reports information by scraping portage logs. And using that process means we can iteratively refine what needs to happen without hamstringing us by being tightly coupled with the portage release process. Once we have a reference and useful enough server and protocol specification, *THEN* we can talk about integrating it with portage and other clients. And its much more likely we'll have competing clients in circulation that speak the protocol than it is that we'll have competing servers all working with a unified client. ^ This much is apparent from observing the CPAN model, we have a variety of client libraries because different ones prove more practical for end users for certain workflows, but we only have one server that is the recipient for the reports. There is of course value in being *ABLE* to provide competing servers, but competing servers are way outside the problem domain that proves relevant to Gentoo. -- Kent KENTNL - https://metacpan.org/author/KENTNL -- Best regards, Igor mailto:lanthrus...@gmail.com
