On 02:20 am, itamar@futurefoundries.com wrote:

On Fri, Mar 15, 2013 at 4:11 AM, Jonathan Jacobs < jonathan+twisted@jsphere.com> wrote:

...

Should the IRI branch be finished before attempting this ticket? (Note that this doesn't necessarily include my volunteering.)

The IRI ticket should *not* be a dependency. It would be nice, but it's unlikely it will happen anytime soon.

The hard part of the IRI ticket is parsing all the extremely complex forms in which an IRI can appear, right? If so, I agree. However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest. Jean-Paul

On Sat, Mar 16, 2013 at 7:52 AM, Jonathan Jacobs < jonathan+twisted@jsphere.com> wrote:

On Sat, Mar 16, 2013 at 3:49 PM, wrote:

...

However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest.

Isn't this currently called twisted.web.client._URL? (Although _URL still needs some more data to fill this role.)

I do like this idea, although I keep coming back to wondering how we provide this to Request initially, an additional parameter was not received with much enthusiasm on IRC. It would be unfortunate if Request.uri is going to mean "the relative URI" forever.

An additional attribute is not ideal... but it's better than changing an existing attribute's contents, which is *really* backwards incompatible. It's probably too late for the ideal solution anyway, let's just get a decent one done.

And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?

Or just IRI.fromString() or something. Why don't you start coding, and we can then talk about actual implementation details? It's going to be pretty short, so any review comments should hopefully not take too long to address. -Itamar

On Mar 16, 2013, at 7:52 AM, Jonathan Jacobs wrote:

And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?

It seems to me that it would be a compatible change to have an IRI.fromString method that could do some extremely straightforward parsing - heck, even ASCII-only! - and then add support for more complex forms later. After all, we have APIs like clientFromString which explicitly support extension; the contract is just (string)->something or (string)->CantGiveYouSomething; the exact format of the string is up to modification. (Although I would suggest that once we have tests for parsing a particular form we should never _remove_ that form...) -glyph