[squeak-dev] Re: The Trunk: Network-ar.82.mcz

Bert Freudenberg bert at freudenbergs.de
Thu Sep 2 10:45:22 UTC 2010


On 02.09.2010, at 11:05, Frank Shearar wrote:

> On 2010/09/02 02:57, Andreas Raab wrote:
>> On 9/1/2010 1:49 PM, Bert Freudenberg wrote:
>>> On 01.09.2010, at 22:22, Frank Shearar wrote:
>>> 
>>>> On 2010/09/01 15:38, Bert Freudenberg wrote:
>>>>> On 01.09.2010, at 10:25, Frank Shearar wrote:
>>>>> 
>>>>>> On 2010/09/01 07:32, commits at source.squeak.org wrote:
>>>>>>> Andreas Raab uploaded a new version of Network to project The Trunk:
>>>>>>> http://source.squeak.org/trunk/Network-ar.82.mcz
>>>>>>> 
>>>>>>> ==================== Summary ====================
>>>>>>> 
>>>>>>> Name: Network-ar.82
>>>>>>> Author: ar
>>>>>>> Time: 1 September 2010, 12:32:08.542 am
>>>>>>> UUID: aa52635f-d746-5744-b432-582c5ba62b11
>>>>>>> Ancestors: Network-ul.81
>>>>>>> 
>>>>>>> Use HttpUrl when dealing with https, i.e.,
>>>>>>> 'https://encrypted.google.com' asUrl class == HttpUrl
>>>>>>> 
>>>>>>> =============== Diff against Network-ul.81 ===============
>>>>>>> 
>>>>>>> Item was changed:
>>>>>>> ----- Method: Url class>>urlClassForScheme: (in category
>>>>>>> 'parsing') -----
>>>>>>> urlClassForScheme: scheme
>>>>>>> (scheme isNil or: [scheme = 'http']) ifTrue: [^HttpUrl].
>>>>>>> + scheme = 'https' ifTrue: [^HttpUrl].
>>>>>>> scheme = 'ftp' ifTrue: [^FtpUrl].
>>>>>>> scheme = 'file' ifTrue: [^FileUrl].
>>>>>>> scheme = 'mailto' ifTrue: [^MailtoUrl].
>>>>>>> scheme = 'browser' ifTrue: [^BrowserUrl].
>>>>>>> ^GenericUrl!
>>>>>> 
>>>>>> That reminds me: for my SipStack I would need to touch this method
>>>>>> (*), as would any other packages using other kinds of URLs.
>>>>>> 
>>>>>> Perhaps we need a registry-based approach, so that we can safely
>>>>>> load multiple URL-defining packages?
>>>>>> 
>>>>>> I see no point in having SipUrl become part of Network, because
>>>>>> most images won't use it. Protocols like HTTP and FTP are pretty
>>>>>> much ubiquitous on the other hand, so it makes sense to keep them
>>>>>> in Network(-Url).
>>>>>> 
>>>>>> frank
>>>>> 
>>>>> The canonical way would be to iterate through Url subclasses in
>>>>> reverse superclass-order to find the most specialized subclass
>>>>> willing to handle a particular scheme.
>>>> 
>>>> OK, I hope my attempt's reasonable. Each subclass says what schemes
>>>> it handles in Foo class>>handlesScheme:. Url
>>>> class>>urlClassForScheme: finds the most specific subclass that will
>>>> accept a particular scheme, by finding the first to say "yes please"
>>>> in Url allSubclasses reverse.
>>>> 
>>>> The package number's not great though: it should be Network-fbs.83,
>>>> adding to Network-ar.82.
>>>> 
>>>> frank
>>> 
>>> Code looks good. But lets hear from people more familiar with the
>>> Network package or URLs if this is the way it should be ...
>> 
>> The code looks okay to me, albeit maybe adding a little more complexity
>> than strictly necessary. I think I would prefer a registration mechanism
>> (simple map of scheme to url class) over the classes queries because
>> there can be situations where you'd like to register schemes with
>> existing URL classes and I find it simpler to say (for example)
>> 
>> RTSPClient class>>initialize
>> "Make sure that rtsp URLs can be handled"
>> 
>> Url registerUrlClass: HierarchicalUrl forScheme: 'rtsp'.
>> 
>> SqueakSSL class>>initialize
>> "Make sure a suitable URL class is registered for https"
>> 
>> (Url urlClassForScheme: 'https') == GenericUrl ifTrue:[
>> "No good; re-register as HttpUrl"
>> Url registerUrlClass: HttpUrl forScheme: 'https'.
>> ].
>> 
>> 
>> instead of having to subclass and implementing #handlesScheme:. But this
>> may be just me :-)
> 
> I'm happy either way: I just want a way to hook schemes to classes without stomping on other packages. My first thought was to have a registry (I like decoupling the class-finding from the inheritance tree), and then Bert reckoned the canonical way would be to ask the subclasses.
> 
> Network-fbs.85 in the inbox implements a registry-based approach.
> 
> frank

Yep, that's more flexible. And more efficient too. Win-win.

However, the registry should be a class variable not class inst variable IMHO.

- Bert -




More information about the Squeak-dev mailing list