What's stopping a Ring 1.0 release?

[James Reeves]

We've reached the stage where:

* Ring is used in production environments
* We worry about maintaining backward compatibility
* We encourage new functionality to be tried out in 3rd-party libraries
* The SPEC and API has been stable for over 6 months

So perhaps we should start considering what we think needs doing
that's preventing a 1.0 stable release.

Here's my attempt at a Ring to-do list, categorized by priority.

+ Things that must be fixed before 1.0
* Fix wrap-lint bug that prevents seqs being recognised as valid
response bodies

+ Things that should be fixed before 1.0
* Allow multipart-params to choose its storage mechanism. Temp-files
aren't allowed on some cloud platforms (e.g. GAE).
* Factor out content-type guessing functions in file-info into their
own utility namespace.

+ Things that would be nice to have for 1.0
(Nothing I can think of that shouldn't begin life as a 3rd-party
library. Accept-parsing should probably be a 3rd-party library at
first.)

+ Things that can wait under version 1.1 or later
* Asynchronous HTTP and Websocket support.

Can anyone else think of anything that we're missing or needs fixing?

Mark, what's your take on this?

- James

[Michael Ossareh]

 * Fix wrap-lint bug that prevents seqs being recognised as valid
response bodies

I took a look at this. Am I incorrect in thinking the solution is this:

https://gist.github.com/b5385bfa633ba586f34b

Assuming not, are there any existing thoughts around how this should behave? I'm willing to take those and implement along with the necessary test cases.

[Shantanu Kumar]

Is :path-uri (and/or :context) going to make it into 1.0?

http://groups.google.com/group/ring-clojure/browse_thread/thread/ae317453a6d10a/b6cf142660de7f42

Regards,
Shantanu

[Shane D]

Michael: Your code doesn't lint seqs of nonstrings, though it certainly is a step in the right direction.

(and (seq? %) (every? string? %))

is a more thorough test for conformance to the spec. `every?` iterates over the seq, though; possibly compromising laziness benefits. Hearing from a laziness expert on this point would be nice.

Hope that helps,

Shane

[James Reeves]

On 26 February 2011 09:29, Shantanu Kumar <kumar.s...@gmail.com> wrote:
> Is :path-uri (and/or :context) going to make it into 1.0?
>
> http://groups.google.com/group/ring-clojure/browse_thread/thread/ae317453a6d10a/b6cf142660de7f42

I suspect not. It's probably something that will be tried out in
third-party libraries (Compojure and lein-ring both support it), and
only when it proves itself a sound solution will it make its way into
Ring.

So more of a 1.1 thing than a 1.0 thing.

- James

[Thomas Scheiblauer]

> + Things that can wait under version 1.1 or later
>   * Asynchronous HTTP and Websocket support.

I would really plead for a.synchronous HTTP... but 1.1 would be ok ;)
Because of this feature I'm currently using 'ztellman/aleph' (combined
with ring and compojure) for my asynchronous "long polling"
toolkit... don't care too much about websockets until they become a
widely implemented browser feature, though.

thx, anyway!

[Michael Ossareh]

On Sat, Feb 26, 2011 at 02:30, Shane D <simr...@gmail.com> wrote:

Michael: Your code doesn't lint seqs of nonstrings, though it certainly is a step in the right direction.

(and (seq? %) (every? string? %))

is a more thorough test for conformance to the spec. `every?` iterates over the seq, though; possibly compromising laziness benefits. Hearing from a laziness expert on this point would be nice.

Perhaps reading a portion of the seq to verify that it is a string? Reading the whole thing before sending seems... costly. That said, it is expected that lint is not run in production so maybe not an issue?

[Shane D]

Michael,

Your point about wrap-lint being a development tool leans me toward a stricter conformance to the spec. If a keyword or other potentially disrupting nonstring worms its way into my code I want to know about it; thus a partial test seems inadequate, and a thorough test much preferred. "Avoid premature optimization" comes to mind. Thanks for the continued discussion.

Sincerely,

Shane

[James Reeves]

On 26 February 2011 10:30, Shane D <simr...@gmail.com> wrote:
> Michael: Your code doesn't lint seqs of nonstrings, though it certainly is a
> step in the right direction.
> (and (seq? %) (every? string? %))
> is a more thorough test for conformance to the spec. `every?` iterates over
> the seq, though; possibly compromising laziness benefits. Hearing from a
> laziness expert on this point would be nice.

I don't think we need to worry about laziness; Clojure should make
that transparent to us.

Also, the SPEC says:

> Each element of the seq is sent to the client as a string.

So the seq doesn't necessarily have to be strings, just objects that
can be turned into strings (e.g. all objects, since everything has a
toString method).

I think we're overthinking this, so I've fixed this with a simple seq?
check and pushed the changes to GitHub. If we happen to need anything
more complex or thorough in future we can do so with another patch.

- James