HTTPServer and SwazooServer servers

> Greetings.
>
> I've started looking at the inner workings of Swazoo and came upon my first
> questions while stepping through SwazooServer demoStart :-)
>
> The short question: The handling of the servers set is somewhat inconsistent.
> Looking at the start method quoted below, the "collection nature" of servers
> is exposed by "(swazoo servers includes: httpServer)", then it is not used
> by "swazoo addServer: httpServer" or (corresponding removals in stop).
> Is there a specific reason for this?
>
> Now for the long question:
>
> I'm guessing that the "canonical" way to access the HTTPServer for a site
> is
>
> SwazooServer singleton serverFor: aSite
>
> SwazooServer>>start (in 2.2.beta1) is implemented as:
>
> SwazooServer>>start
> | swazoo |
> swazoo := SwazooServer singleton.
> [self aliases do: [:each | | httpServer |
> httpServer := swazoo serverFor: each.
> httpServer addSite: self.
> (swazoo servers includes: httpServer)
> ifFalse:
> [swazoo addServer: httpServer.
> httpServer isServing ifFalse: [httpServer start] ] ].
> ] ifCurtailed: [self stop].
> self serving: true.
>
> where
>
> SwazooServer>>serverFor: aSiteIdentifier
> ^self servers
> detect: [:each | (each ip = aSiteIdentifier ip) & (each port = aSiteIdentifier port)]
> ifNone: [self newServerFor: aSiteIdentifier]
>
>
> How much harm would be caused by the following approach:
>
> SwazooServer>>serverFor:
> ^self servers
> detect: [:each | (each ip = aSiteIdentifier ip) & (each port = aSiteIdentifier port)]
> ifNone: [self addServer: (self newServerFor: aSiteIdentifier)]
>
> and
>
> SwazooServer>>start
> | swazoo |
> swazoo := SwazooServer singleton.
> [self aliases do: [:each | | httpServer |
> httpServer := swazoo serverFor: each.
> httpServer addSite: self.
> httpServer isServing ifFalse: [httpServer start] ].
> ] ifCurtailed: [self stop].
> self serving: true.
>
> If I understand the code correctly, an "unknown" server is added to the servers set,
> however, the server in question already comes from the set or has just been created
> and is definitely not in the set. Resolving this difference earlier shortens the start method.
>
> The original approach would only start new httpServers, while the latter would start
> servers for all known aliases. So you could theoretically end up with an alias hooked up
> to a non-running httpServer. When is this useful?
>
>
> Just making Smalltalk,
> s.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/swazoo-devel
>

> Hi Stefan, welcome to the Swazoo list!
>
> For your suggested change, it seems it should work, so I propose that
> you just implement and test it, then let us know. I can also start
> testing by myself. Well, let me start then ...
>
> Janko
>
>
> Stefan Schmiedl wrote:
>> Greetings.
>>
>> I've started looking at the inner workings of Swazoo and came upon my first
>> questions while stepping through SwazooServer demoStart :-)
>>
>> The short question: The handling of the servers set is somewhat inconsistent.
>> Looking at the start method quoted below, the "collection nature" of servers
>> is exposed by "(swazoo servers includes: httpServer)", then it is not used
>> by "swazoo addServer: httpServer" or (corresponding removals in stop).
>> Is there a specific reason for this?
>>
>> Now for the long question:
>>
>> I'm guessing that the "canonical" way to access the HTTPServer for a site
>> is
>>
>> SwazooServer singleton serverFor: aSite
>>
>> SwazooServer>>start (in 2.2.beta1) is implemented as:
>>
>> SwazooServer>>start
>> | swazoo |
>> swazoo := SwazooServer singleton.
>> [self aliases do: [:each | | httpServer |
>> httpServer := swazoo serverFor: each.
>> httpServer addSite: self.
>> (swazoo servers includes: httpServer)
>> ifFalse:
>> [swazoo addServer: httpServer.
>> httpServer isServing ifFalse: [httpServer start] ] ].
>> ] ifCurtailed: [self stop].
>> self serving: true.
>>
>> where
>>
>> SwazooServer>>serverFor: aSiteIdentifier
>> ^self servers
>> detect: [:each | (each ip = aSiteIdentifier ip) & (each port = aSiteIdentifier port)]
>> ifNone: [self newServerFor: aSiteIdentifier]
>>
>>
>> How much harm would be caused by the following approach:
>>
>> SwazooServer>>serverFor:
>> ^self servers
>> detect: [:each | (each ip = aSiteIdentifier ip) & (each port = aSiteIdentifier port)]
>> ifNone: [self addServer: (self newServerFor: aSiteIdentifier)]
>>
>> and
>>
>> SwazooServer>>start
>> | swazoo |
>> swazoo := SwazooServer singleton.
>> [self aliases do: [:each | | httpServer |
>> httpServer := swazoo serverFor: each.
>> httpServer addSite: self.
>> httpServer isServing ifFalse: [httpServer start] ].
>> ] ifCurtailed: [self stop].
>> self serving: true.
>>
>> If I understand the code correctly, an "unknown" server is added to the servers set,
>> however, the server in question already comes from the set or has just been created
>> and is definitely not in the set. Resolving this difference earlier shortens the start method.
>>
>> The original approach would only start new httpServers, while the latter would start
>> servers for all known aliases. So you could theoretically end up with an alias hooked up
>> to a non-running httpServer. When is this useful?
>>
>>
>> Just making Smalltalk,
>> s.
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Swazoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/swazoo-devel
>>
>