On 08/17/2012 02:07 PM, Branko Čibej wrote:
> On 17.08.2012 20:01, C. Michael Pilato wrote:
>> On 08/17/2012 12:43 PM, Daniel Shahaf wrote:
>>> Stefan Sperling wrote on Fri, Aug 17, 2012 at 18:24:03 +0200:
>>>> On Fri, Aug 17, 2012 at 12:14:31PM -0400, C. Michael Pilato wrote:
>>>>> 4. something else?
>>>> 4. Marshall the version string before sending it across svn://,
>>>> escaping unsupported characters somehow in a reversible way,
>>>> and unescape them before passing them to hooks?
>>>> I.e. use something like strnvis() but adapted to the
>>>> restrictions of the svn:// protocol.
>> Yeah, I forgot to add that I was thinking about this approach, too. I'm not
>> familiar with strnvis(), but I assume it's similar to what we do with our
>> checksum API _readable() variants (where 'A' is 0x41 and represented as as
>> "41")?
>>
>>> 5. Require the version string and client name to match
>>> /^[A-Za-z0-9-]+$/, and embed them directly as part of a capability
>>> name (so: capabilities might be named client-version-tsvn-1dot7dot0)
>> I'll give the honor of treating this suggestion as a serious one. And then
>> the dishonor of a hearty -1. :-)
>
> Why? It's essentially the same as 4., just with a different and
> higher-level marshalling.
Because it is higher-level marshaling. The ideal scenario keeps our
restrictions and conversion costs as close to the layers that actually
require them as possible.
I'm sitting at this spot right now: Unless we want hooks parsing literal
capability strings such as "client-version-tsvn-1dot7dot0", we have to
change the server. And if we have to change the server *at all* to make
this all work, then we should simultaneously change the protocol so as not
to require some still-obscure marshaling mechanism.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-17 20:34:16 CEST