On 2012-12-14 6:47 PM, Frank Shearar wrote:
> On 14 December 2012 23:20, Chris Cunnington
> <smalltalktelevision at gmail.com> wrote:
>> On 2012-12-14 4:43 PM, Frank Shearar wrote:
>>> Should ALPath decode a request's path?
>>>
>>> In particular, I'm mucking around again with reflecting images with
>>> Altitude, and send a GET to
>>> http://127.0.0.1:9090/organization/classes-in/Graphics-Display%20Objects
>>>
>>> I'd expected the resulting ALPath such that path third =
>>> 'Graphics-Display Objects', but it's actually path third =
>>> 'Graphics-Display%20Objects'.
>> You're first string cannot be used as a url. The %20 gets added to fill the
>> space. It's there because 'as is' your string cannot be used in a url. Added
>> to which, if you are presenting classes from an image, you have an unusual
>> resource. Perhaps you should create a new kind of resource for that (i.e.
>> ALImageClassResource  as opposed to ALFormResource, ALHtmlResource,
>> ALCallbackResource, ALJSONResource)?
> I know why the %20 appears - because I (have to) URL encode things
> that go into a URL.
This problem seems like GIGO. Perhaps you are putting untreated input 
into a process and then not getting the desired result.
> My point is that I'd expected the parser to
> un-escape percent-encoded URL parts, because that encoding is part of
> how HTTP works, not part of how the application works. (But I suppose
> that the current behaviour is symmetrical: you have to encode strings
> yourself, and you have to decode strings yourself.)

I'm pretty certain there is an API for adding HTTP streaming treatment. 
If you want to add something from a RFC, then add a Relay to do it. Look 
at ALTerminalRelay, ALStorageRelay. Add your filter there and not in 
ALHttpParser. I bet you could find one of the many Xtreams 
filters/transforms to do what you want, put it in a relay, and solve 
your problem. See Xtreams-Transforms. I sort of feel everything in 
Altitude is a stream.
>
> I use ALJsonResource instances, actually.
I think I recall now.
>   I don't surface the classes
> directly: I'm basically (re-)implementing SystemOrganizer's and
> ClassOrganizer's APIs locally, and serving up chunks of strings
> remotely. For instance,
>
> ReflectedSystemCategories >> renderSystemCategoriesOn: json
> 	json object: [
> 		json name: 'type' value: 'system-categories'.
> 		json name: 'category-names' array: [
> 			SystemOrganizer default categories do: [:cat |
> 				json value: cat]]]
Perhaps you should subclass ALJSONResource so you can treat:

                     SystemOrganizer default categories do:

to produce input that doesn't leave spaces in string names. If I 
understand your problem correctly, you wouldn't have this problem if you 
treated your input.

Chris


> (I'm trying out the idea of faking these APIs to turn a Browser
> (subclass) into a RemoteBrowser. Sort've a follow-on/extension of
> Reflect-Core's experiment. First thing to note: you really want to
> memoize the calls, because Browser makes A LOT of calls to the
> organizers - every time it renders itself, in fact.)
>
> frank
>
>> At any rate, I sort of think that what you want to change should be before
>> things go 'into the pipe' or afterwards. In your application, as opposed to
>> the framework.
>>
>> Just a thought,
>> Chris
>>
>>
>>> >From my reading of RFC 3986 [1], especially sections 2.5 and 7.3, it
>>> seems like (a) it's up to the scheme definition as to how to encode
>>> things (beyond encoding reserved characters) and that (b) usually
>>> that's string -> utf-8 -> %-encoding.
>>>
>>> What do you think? Should ALPath (or ALHttpParser during construction
>>> of same) be responsible for shielding the application from the
>>> vagaries of HTTP's encoding rules?
>>>
>>> frank
>>>
>>> [1] http://tools.ietf.org/html/rfc3986
>>>
>>