On 06/05/2013 04:04, Graydon Hoare wrote:
How do you fork a requirement? (or discussion thereof?)
How do you fork a design? (or discussion thereof?)
It depends. If there's something specific to comment on, we don't mean
to discourage discussion thereof. Specificity is in the eye of the
beholder I guess. Tim's judgment (that, in this case, I quite agreed
with) was that this thread had gone well off the rails into abstract
lecturing. I did some of it -- I probably should have sent a shorter
and more polite email in the one-previous -- you did some, Nathan did
some. It wasn't getting anywhere, and it's exactly the sort of thread
that policy was intended to remind us to hold our tongues during. They
just make everyone's blood boil, produce nothing useful.
I think the issue here is that it is not entirely clear what kind of
problem the libraries are trying to solve, and who for. Plenty of us
have experience writing server processes and this has historically
involved quite low-level coding. Its quite reasonable for Rust to
target something else (its not as if Ruby does, for example) and yet be
useful. I thought this was a real discussion about what the requirement
(or multiple diverse requirements sets) are.
Maybe I'm old fashioned, but I can't imagine day-job being materially
different to:
- requirement
- analysis
- estimation
- sponsorship
- resourcing
- implementation and testing
Its clear that there are iterations to be had in much of this, but with
something very fundamental, failing to understand and agree and record
and publicise the requirements is a basis for later pain.
And I would expect that to hold whether or not the later phases occur
formally in a less formal environment.
In this particular case, it is not easy to see how a reliance on
lightweight switching at a task layer can work in practice on all
interesting platforms; but its also true that it doesn't matter whether
the behaviour now is 'good enough' so long as there is some clarity
about what the expected goal is.
If the reality is a desire to make it easy to solve server scalability
that will work for most problems, most of the time - and that there is
no ambition that this framework would solve more extreme requirements -
then that's fine, but I think it worth stating clearly if so. (I also
think its a shame, because everything layered upon it like address
resolution and http server loops and codec pipelines etc that will
surely come will also have the same inherited limitations, but that
might just be tough.)
It seems to be the old 'show me the code'. :-(
It's a plea to remain constructive and focused on actual problems;
In this case I think the problem is very much 'what is the requirement?'
And that _is_ necessarily abstract for something like this, but that
does not preclude clarity.
James
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
