Re: Proposal for a simple plan Lassi Kortela 13 Jul 2019 16:57 UTC
> You just described my wife and me - and the getting along part is the > tricky part ;) Coding-wise I swing between both ends, depending on task > on environment, but in either case I try to keep Eisenhower's wisdom in > mind: "plans are useless, but planning is indispensable". Heh. That's one of my favorite quotes too :) > I thought the clients and server can (and should) co-evolve constantly. > > I fail to understand how, without having some upfront spec. If we want > to minimize upfront planning and white-papers, we need something to code > against, so we could simple let the server-side code talk and the > client-side follow. Setting up the server and implementing 3 APIs should > be a short enough lead to not thwart the overall development process > significantly. This again depends on the protocol. Since GraphQL is based on an object model, it's pretty uncontroversial how to find the classes. E.g. a Scheme API would have an Implementation class, a SRFI class, a Report class for RnRS (or a combined Document class into which both SRFI and RnRS fit). A Package class for libraries in package managers like Akku, etc. Those again have straightforward queries: get all implementations, get implementation by its id ("chibi", "kawa", etc.) Then various search queries (e.g. list all packages with "xyz" in their name). With REST it's more complex because you have to also design the response formats, which are the hardest things to design (and the more time passes, the harder it is to keep them clean). > If we choose GraphQL, it solves this problem handily because the API > response format is completely client-dictated. > > That's again not fitting squarely into my brain ;) If we just imagine > two Scheme clients and an Emacs client, I think that they can share so > much more than just what they expect from the server - and I would hope > that we would greatly improve the quality of the client implementations > by sharing common best practices and ideas as they come up during > development. If so, that sharing can be heavily simplified by not > starting from completely opposite ends. Admittedly the tricky part in > this case is to find the right balance between alignment and creative > flow of thoughts, but this anyway our daily business. I'd leave it up to the people writing the clients to figure out how to best work together. People usually know what works best for them, and it's different for everybody. So for example, if one person is most enthusiastic about making an Emacs client, and another about a CLI client, then they can each work on those clients and find a way to communicate that is the best match for their personal styles. It's definitely nice if clients can share code, but there are times when code sharing gets in the way (by slowing down development, or if the clients need almost the same thing but with some variations, and the variation makes communication slow or code complex). I think the best way to do this is that people start writing the clients, and then they discover what makes the most sense. They can always be refactored later. For me, the overarching concern is that I've been in many projects where lots of time is spent debating things that not based on any field experience. It's faster (and usually more fun) to gain real experience as fast as possible by trying things. Often the results are surprising. Software is so complex that the right solution or approach is usually not obvious beforehand. So for the most part, I'd be in the "code wins arguments" camp.