8
\$\begingroup\$

The rules for this 'exchange state quite clearly that discussion of

Higher-level architecture and design of software systems [...] is off-topic for this site.

However, I'm wondering if we might bend the rules a bit in the case of asking for reviews of a protocol specification. The reason I ask is because, well... I just spent about half an hour writing a post asking for reviews of a secure communications protocol I designed for a very specific task, including a full specification of the protocol that could be used (and is indeed the one I intend to use) to implement a system that uses the protocol, only to double-check the rules page (which is damned hard to find by the way) and find that there's no way I could get away with actually posting it.

My rationale for this suggestion is pretty simple:

  1. Critiquing a protocol spec isn't that different from critiquing actual code; indeed, you can think of it as an implementation that's been written in English.
  2. There's nowhere better to go with such a thing.

On the other hand, I doubt anyone wants to have random jackasses coming on here asking for critique of a some half thought-out idea they had for a program, algorithm, or system design, and limiting this place to just critiques of actual written code stops that pretty handily.

Still, I think we can avoid that by allowing protocol specifications so long as they amount to what I described as "programs written in English".

\$\endgroup\$
  • 2
    \$\begingroup\$ You've done the right thing - when in doubt, ask on meta! \$\endgroup\$ – Mathieu Guindon May 6 '14 at 2:18
  • \$\begingroup\$ @rolfl Well, I did just now. While I agree that I'm sitting right on the borderline here, I'd argue that I'm not asking about the design of the protocol- I've already designed it- but about the protocol itself, and what issues might arise upon, as Rommel put it, "contact with the enemy". \$\endgroup\$ – Schilcote May 6 '14 at 2:26
  • 4
    \$\begingroup\$ An update.... The Programmer folk suggested you should discuss this on their chat site: The WhiteBoard \$\endgroup\$ – rolfl May 6 '14 at 3:05
  • \$\begingroup\$ Feel free to re-ask this question on Meta Programmers. There is conflicting thought regarding whether or not your suggested question would be on-topic for Progs. \$\endgroup\$ – GlenH7 May 6 '14 at 13:55
9
\$\begingroup\$

Unfortunately, this is clearly off-topic on Code Review. Programmers comes to mind as being the most suited Stack Exchange destination for questions like this..... But, i have communicated with a Programmers moderator, and it appears it would be considered too broad there...

One of the firmly enforced 'rules' on Code Review, is that there has to be Code to review. Now, if you were to document your protocol, and present the implementing code, then, it could be reviewed, but, as it is, no. The question would not be on topic.

The question remains... where would be the best place?

\$\endgroup\$
  • \$\begingroup\$ Well, that's an idea (write an implementation and get that reviewed, that is)... except the implementation I have of it doesn't work correctly, and I'm not sure if it's a bug in the implementation that I can't figure out or if it's an inherent issue with how the protocol works. \$\endgroup\$ – Schilcote May 7 '14 at 2:12
  • \$\begingroup\$ @Schilcote - you should definitely consider asking this question over on the programmers' meta. This has created some discussion in the mod world... and it's a good meta question \$\endgroup\$ – rolfl May 7 '14 at 2:16
5
\$\begingroup\$

A review of your protocol design would be clearly against the current rules. The follow-up question might be, why not change the rules to expand the scope of this site?

I believe that our requirement to include real, working code serves as a good filter to ensure that we have high-quality questions. Making an exception to allow protocol reviews would open the door to all kinds of requests to vet half-finished ideas.

In any case, one reliable indicator of a good API or protocol design is whether it is possible to come up with two independent implementations of it. If you try to implement your protocol, you will likely discover design issues along the way. Therefore, I think it is reasonable for Code Review to uphold the simple rule that you must include a working implementation for consideration.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .