We run Seaside 3 in production on GLASS where we proxy all requests to Seaside from nginx. The production machine has many ip addresses on it. As an example, it might have something like
127.0.0.1 192.168.1.1 192.168.1.2 etc
where all the 192.168.1.* ips are public facing.
Each port that seaside is available on, is available on all ips. Instead of having to go through the proxy, you can connect directly to swazoo by going to 192.168.1.1:9001.
I've done a patch for GLASS that allows you to specify a specific ip address to listen on rather than all interfaces. It requires a change to the Seaside-Core swazoo adapter. I'd like to get that change into Seaside so I don't have to worry about mainting the changes.
What is the best way to go about submitting the change ( I have a .mcz of the changes from a couple months ago )? And are there other adapters I should make the same changes to for Seaside 3?
I've patched my image to have
WAComancheAdaptor>>createService ^ (HttpService on: self port) address: '127.0.0.1'; name: 'seaside-' , self port greaseString; plug: self; yourself
so yeah if you're making a setting/user interface for this, change comanche too
rado
On Sat, 27 Mar 2010, Sean Allen wrote:
We run Seaside 3 in production on GLASS where we proxy all requests to Seaside from nginx. The production machine has many ip addresses on it. As an example, it might have something like
127.0.0.1 192.168.1.1 192.168.1.2 etc
where all the 192.168.1.* ips are public facing.
Each port that seaside is available on, is available on all ips. Instead of having to go through the proxy, you can connect directly to swazoo by going to 192.168.1.1:9001.
I've done a patch for GLASS that allows you to specify a specific ip address to listen on rather than all interfaces. It requires a change to the Seaside-Core swazoo adapter. I'd like to get that change into Seaside so I don't have to worry about mainting the changes.
What is the best way to go about submitting the change ( I have a .mcz of the changes from a couple months ago )? And are there other adapters I should make the same changes to for Seaside 3? _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Sun, Mar 28, 2010 at 10:47:59AM +0200, radoslav hodnicak wrote:
WAComancheAdaptor>>createService ^ (HttpService on: self port) address: '127.0.0.1'; name: 'seaside-' , self port greaseString; plug: self; yourself
In case anyone prefers serving static files from Comanche instead of using WAFileLibrary, here's an adaptation to Seaside 3 of some old code you may find on the net. (Note, I don't have the binding to 127.0.0.1 below.)
WAComancheAdaptor>>createServiceWithStaticPlug | contentPath dirPath service ma |
contentPath := 'htdocs'. dirPath := FileDirectory default fullNameFor: contentPath. service := HttpService on: self port named: 'seaside-', self port greaseString. ma := ModuleAssembly core. ma alias: '/static' to: [ ma serverRoot: dirPath. ma documentRoot: dirPath. ma directoryIndex: 'index.html index.htm'. ma serveFiles ]. ma addPlug: self. service plug: ma rootModule. ^ service
While people are discussing these kinds of things, I just thought I'd through in a reminder that you should feel free to implement your own subclass of any of the server adaptors if you want custom behaviour. This may make custom modifications that we don't adopt easier to manage, and of course they will show up in the menu in the Control Panel just like any other adaptor.
Julian
On Mon, Mar 29, 2010 at 1:05 PM, Pierce Ng pierce@netmemetic.com wrote:
On Sun, Mar 28, 2010 at 10:47:59AM +0200, radoslav hodnicak wrote:
WAComancheAdaptor>>createService ^ (HttpService on: self port) address: '127.0.0.1'; name: 'seaside-' , self port greaseString; plug: self; yourself
In case anyone prefers serving static files from Comanche instead of using WAFileLibrary, here's an adaptation to Seaside 3 of some old code you may find on the net. (Note, I don't have the binding to 127.0.0.1 below.)
WAComancheAdaptor>>createServiceWithStaticPlug | contentPath dirPath service ma |
contentPath := 'htdocs'. dirPath := FileDirectory default fullNameFor: contentPath. service := HttpService on: self port named: 'seaside-', self port greaseString. ma := ModuleAssembly core. ma alias: '/static' to: [ ma serverRoot: dirPath. ma documentRoot: dirPath. ma directoryIndex: 'index.html index.htm'. ma serveFiles ]. ma addPlug: self. service plug: ma rootModule. ^ service
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Mon, Mar 29, 2010 at 8:54 AM, Julian Fitzell jfitzell@gmail.com wrote:
While people are discussing these kinds of things, I just thought I'd through in a reminder that you should feel free to implement your own subclass of any of the server adaptors if you want custom behaviour. This may make custom modifications that we don't adopt easier to manage, and of course they will show up in the menu in the Control Panel just like any other adaptor.
Unfortunately in my case where the adapter is used by other GLASS code, that still doesn't really solve the problem.
How do you mean "used by GLASS code"? The server adaptor is what drives the whole process. Even if GLASS has an adaptor registered by default, you should be able to stop/remove it and run your own - no?
Julian
On Mon, Mar 29, 2010 at 2:43 PM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 8:54 AM, Julian Fitzell jfitzell@gmail.com wrote:
While people are discussing these kinds of things, I just thought I'd through in a reminder that you should feel free to implement your own subclass of any of the server adaptors if you want custom behaviour. This may make custom modifications that we don't adopt easier to manage, and of course they will show up in the menu in the Control Panel just like any other adaptor.
Unfortunately in my case where the adapter is used by other GLASS code, that still doesn't really solve the problem. _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
In GLASS there is:
WASwazooAdaptor subclass: 'WAGsSwazooAdaptor'
Which just makes it ugly one way or another. The only difference is the addition of a couple methods that allow you to specificy the ip address to listen on to the underlying Swazoo server. It doesnt break any existing code so for me, it would be easier to keep patching in the methods rather than try to track what might be needed in new GS adaptors.
Really, I would just like the modify the existing Seaside adaptors to allow for the setting a specific ip to bind to.
On Mon, Mar 29, 2010 at 10:40 AM, Julian Fitzell jfitzell@gmail.com wrote:
How do you mean "used by GLASS code"? The server adaptor is what drives the whole process. Even if GLASS has an adaptor registered by default, you should be able to stop/remove it and run your own - no?
Julian
On Mon, Mar 29, 2010 at 2:43 PM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 8:54 AM, Julian Fitzell jfitzell@gmail.com wrote:
While people are discussing these kinds of things, I just thought I'd through in a reminder that you should feel free to implement your own subclass of any of the server adaptors if you want custom behaviour. This may make custom modifications that we don't adopt easier to manage, and of course they will show up in the menu in the Control Panel just like any other adaptor.
Unfortunately in my case where the adapter is used by other GLASS code, that still doesn't really solve the problem. _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
The question I guess is how should you specify the interface? Is an IP string good enough?
Julian
On Mon, Mar 29, 2010 at 4:44 PM, Sean Allen sean@monkeysnatchbanana.com wrote:
In GLASS there is:
WASwazooAdaptor subclass: 'WAGsSwazooAdaptor'
Which just makes it ugly one way or another. The only difference is the addition of a couple methods that allow you to specificy the ip address to listen on to the underlying Swazoo server. It doesnt break any existing code so for me, it would be easier to keep patching in the methods rather than try to track what might be needed in new GS adaptors.
Really, I would just like the modify the existing Seaside adaptors to allow for the setting a specific ip to bind to.
On Mon, Mar 29, 2010 at 10:40 AM, Julian Fitzell jfitzell@gmail.com wrote:
How do you mean "used by GLASS code"? The server adaptor is what drives the whole process. Even if GLASS has an adaptor registered by default, you should be able to stop/remove it and run your own - no?
Julian
On Mon, Mar 29, 2010 at 2:43 PM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 8:54 AM, Julian Fitzell jfitzell@gmail.com wrote:
While people are discussing these kinds of things, I just thought I'd through in a reminder that you should feel free to implement your own subclass of any of the server adaptors if you want custom behaviour. This may make custom modifications that we don't adopt easier to manage, and of course they will show up in the menu in the Control Panel just like any other adaptor.
Unfortunately in my case where the adapter is used by other GLASS code, that still doesn't really solve the problem. _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Mon, Mar 29, 2010 at 7:06 PM, Julian Fitzell jfitzell@gmail.com wrote:
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
I dont think so,
The question I guess is how should you specify the interface? Is an IP string good enough?
Yes.
I already did the work for the Swazoo adapter. I'll take on the work of doing that and the others. Its my itch, I'll scratch it.
Should I do for 2.8 and 3.0 or just 3.0?
Is the best thing to do:
create an issue. attached .mcz files to the issue
?
On Tue, Mar 30, 2010 at 1:44 AM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 7:06 PM, Julian Fitzell jfitzell@gmail.com wrote:
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
I dont think so,
Here it is:
http://code.google.com/p/seaside/issues/detail?id=360
The question I guess is how should you specify the interface? Is an IP string good enough?
Yes.
I already did the work for the Swazoo adapter. I'll take on the work of doing that and the others. Its my itch, I'll scratch it.
Should I do for 2.8 and 3.0 or just 3.0?
Is the best thing to do:
create an issue. attached .mcz files to the issue
Sure, or upload to:
MCHttpRepository location: 'http://www.squeaksource.com/SeasideInbox' user: '' password: ''
Julian
Julian,
I did this for Swazoo. It was 5 minutes of work. I haven't done for Comanche yet, wanted to get some feedback first.
The Comanche adapter uses HTTPService which descends from TcpService to register itself. TcpService has the ability in theory to do ip and port because of this instance side method:
initializeOnPort:address:priority:
However, nowhere else in the comanche code can i see it ever using the priority or address anywhere.
From what I can see, its incomplete and only capable at this time of
doing by port. The Comanche code is obviously outside the scope of seaside so I'm not sure how to proceed.
Should I only implement for Swazoo ( done ) and call it a day or should I talk to Goran about adding the required functionality to Comanche and hold back the changes til then.
Additionally, should I an additional popup when configuring an adaptor via the control panel so that it prompts for port and ip or should i leave this as functionality you can get at if you don't use the control panel? I need this for running on Gemstone so control panel isn't an issue for me, but I can add if its desired.
Last but not least, the listener adapter, add functionality to it as well? ( I haven't looked at it yet in anything other than a cursory fashion ). And the test adapter, not needed for that correct?
-Sean-
On Tue, Mar 30, 2010 at 4:08 AM, Julian Fitzell jfitzell@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:44 AM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 7:06 PM, Julian Fitzell jfitzell@gmail.com wrote:
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
I dont think so,
Here it is:
http://code.google.com/p/seaside/issues/detail?id=360
The question I guess is how should you specify the interface? Is an IP string good enough?
Yes.
I already did the work for the Swazoo adapter. I'll take on the work of doing that and the others. Its my itch, I'll scratch it.
Should I do for 2.8 and 3.0 or just 3.0?
Is the best thing to do:
create an issue. attached .mcz files to the issue
Sure, or upload to:
MCHttpRepository location: 'http://www.squeaksource.com/SeasideInbox' user: '' password: ''
Julian _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi Sean,
Not sure... I guess we either put the instVar on the abstract ServerAdaptor and ignore it on subclasses that don't support it or you just implement it on the Swazoo adaptor and we pull it up whenever we're ready to implement it elsewhere. I don't think it matters too much, so just do what's easiest. If the ListenerAdaptor is using HTTP internals direectly enough that it's easy, that would be a good reason to pull it up.
If you feel like chasing up Göran/Giovanni to see about extending Comanche to support it, though, that would be awesome!
And, yes, it would be nice to have support for it in the control panel if you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
Julian
On Tue, Apr 20, 2010 at 2:24 AM, Sean Allen sean@monkeysnatchbanana.comwrote:
Julian,
I did this for Swazoo. It was 5 minutes of work. I haven't done for Comanche yet, wanted to get some feedback first.
The Comanche adapter uses HTTPService which descends from TcpService to register itself. TcpService has the ability in theory to do ip and port because of this instance side method:
initializeOnPort:address:priority:
However, nowhere else in the comanche code can i see it ever using the priority or address anywhere.
From what I can see, its incomplete and only capable at this time of
doing by port. The Comanche code is obviously outside the scope of seaside so I'm not sure how to proceed.
Should I only implement for Swazoo ( done ) and call it a day or should I talk to Goran about adding the required functionality to Comanche and hold back the changes til then.
Additionally, should I an additional popup when configuring an adaptor via the control panel so that it prompts for port and ip or should i leave this as functionality you can get at if you don't use the control panel? I need this for running on Gemstone so control panel isn't an issue for me, but I can add if its desired.
Last but not least, the listener adapter, add functionality to it as well? ( I haven't looked at it yet in anything other than a cursory fashion ). And the test adapter, not needed for that correct?
-Sean-
On Tue, Mar 30, 2010 at 4:08 AM, Julian Fitzell jfitzell@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:44 AM, Sean Allen sean@monkeysnatchbanana.com
wrote:
On Mon, Mar 29, 2010 at 7:06 PM, Julian Fitzell jfitzell@gmail.com
wrote:
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
I dont think so,
Here it is:
http://code.google.com/p/seaside/issues/detail?id=360
The question I guess is how should you specify the interface? Is an IP string good enough?
Yes.
I already did the work for the Swazoo adapter. I'll take on the work of doing that and the others. Its my itch, I'll scratch it.
Should I do for 2.8 and 3.0 or just 3.0?
Is the best thing to do:
create an issue. attached .mcz files to the issue
Sure, or upload to:
MCHttpRepository location: 'http://www.squeaksource.com/SeasideInbox' user: '' password: ''
Julian _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Tue, Apr 20, 2010 at 3:53 AM, Julian Fitzell jfitzell@gmail.com wrote:
Hi Sean,
Not sure... I guess we either put the instVar on the abstract ServerAdaptor and ignore it on subclasses that don't support it or you just implement it on the Swazoo adaptor and we pull it up whenever we're ready to implement it elsewhere. I don't think it matters too much, so just do what's easiest. If the ListenerAdaptor is using HTTP internals direectly enough that it's easy, that would be a good reason to pull it up
I'll look into the listener adaptor in the next couple days.
.
If you feel like chasing up Göran/Giovanni to see about extending Comanche to support it, though, that would be awesome!
Will look into that as well.
And, yes, it would be nice to have support for it in the control panel if you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
Swazoo seems to do '*' as the default. I'll see how it responds to 0.0.0.0.
I've never done anything GUI related with pharo etc so, once I do it, I'll be sending you the code to make sure I didn't do anything non portable.
A Matter of style.
Related to the listener adapter.
Swazoo uses '*' to indicate all interfaces. I originally coded for that. Should I keep that as the 'all interfaces'? It results in the swazoo code not needing special logic but any other adapters might. Case in point, the listener adapter. Its a different method call if you want to listen on all vs just 1. Highlighted below in between the -----'s is what would be in the listener adapter. Not sure how the core team feels about code like this. I don't honestly see much of a better way as this is isolated to one spot in one method.
listenLoop | socket | socket := Socket newTCP. ---- ip = '*' ifTrue: [ socket listenOn: port backlogSize: 50. ] ifFalse: [ socket listenOn: port backlogSize: 50 interface: ip asIpByteArray asSocketAddress. ]. ---- socket isValid ifFalse: [ self error: 'Cannot listen on interface ', ip greaseString,' port ' , port greaseString ]. [ [ socket isValid ifFalse: [ ^ self listenLoop ]. self waitForConnection: socket ] repeat ] ifCurtailed: [ (Delay forMilliseconds: 10) wait. socket destroy ]
I could move the backlogSize out so the 50 is harcoded as a magic number in two points but other than that, without getting overly complicated, I can't think of a better way to address.
On Tue, Apr 20, 2010 at 3:53 AM, Julian Fitzell jfitzell@gmail.com wrote:
Hi Sean,
Not sure... I guess we either put the instVar on the abstract ServerAdaptor and ignore it on subclasses that don't support it or you just implement it on the Swazoo adaptor and we pull it up whenever we're ready to implement it elsewhere. I don't think it matters too much, so just do what's easiest. If the ListenerAdaptor is using HTTP internals direectly enough that it's easy, that would be a good reason to pull it up.
If you feel like chasing up Göran/Giovanni to see about extending Comanche to support it, though, that would be awesome!
And, yes, it would be nice to have support for it in the control panel if you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
Julian
On Tue, Apr 20, 2010 at 2:24 AM, Sean Allen sean@monkeysnatchbanana.com wrote:
Julian,
I did this for Swazoo. It was 5 minutes of work. I haven't done for Comanche yet, wanted to get some feedback first.
The Comanche adapter uses HTTPService which descends from TcpService to register itself. TcpService has the ability in theory to do ip and port because of this instance side method:
initializeOnPort:address:priority:
However, nowhere else in the comanche code can i see it ever using the priority or address anywhere.
From what I can see, its incomplete and only capable at this time of
doing by port. The Comanche code is obviously outside the scope of seaside so I'm not sure how to proceed.
Should I only implement for Swazoo ( done ) and call it a day or should I talk to Goran about adding the required functionality to Comanche and hold back the changes til then.
Additionally, should I an additional popup when configuring an adaptor via the control panel so that it prompts for port and ip or should i leave this as functionality you can get at if you don't use the control panel? I need this for running on Gemstone so control panel isn't an issue for me, but I can add if its desired.
Last but not least, the listener adapter, add functionality to it as well? ( I haven't looked at it yet in anything other than a cursory fashion ). And the test adapter, not needed for that correct?
-Sean-
On Tue, Mar 30, 2010 at 4:08 AM, Julian Fitzell jfitzell@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:44 AM, Sean Allen sean@monkeysnatchbanana.com wrote:
On Mon, Mar 29, 2010 at 7:06 PM, Julian Fitzell jfitzell@gmail.com wrote:
Ok, fair enough. And yes we should add it. (isn't there an issue open for that somewhere?)
I dont think so,
Here it is:
http://code.google.com/p/seaside/issues/detail?id=360
The question I guess is how should you specify the interface? Is an IP string good enough?
Yes.
I already did the work for the Swazoo adapter. I'll take on the work of doing that and the others. Its my itch, I'll scratch it.
Should I do for 2.8 and 3.0 or just 3.0?
Is the best thing to do:
create an issue. attached .mcz files to the issue
Sure, or upload to:
MCHttpRepository location: 'http://www.squeaksource.com/SeasideInbox' user: '' password: ''
Julian _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2010/4/20 Julian Fitzell jfitzell@gmail.com:
Hi Sean,
Not sure... I guess we either put the instVar on the abstract ServerAdaptor and ignore it on subclasses that don't support it or you just implement it on the Swazoo adaptor and we pull it up whenever we're ready to implement it elsewhere. I don't think it matters too much, so just do what's easiest. If the ListenerAdaptor is using HTTP internals direectly enough that it's easy, that would be a good reason to pull it up.
If you feel like chasing up Göran/Giovanni to see about extending Comanche to support it, though, that would be awesome!
And, yes, it would be nice to have support for it in the control panel if you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
I'd probably put a String (preferably '0.0.0.0' and not '*') in the server adapter and do all the conversion and adaptation there. If the adapter doesn't support it then just do nothing. It would be nice if the status string would reflect the interface the server is listening on.
Cheers Philippe
On Tue, Apr 20, 2010 at 12:13 PM, Philippe Marschall philippe.marschall@gmail.com wrote:
2010/4/20 Julian Fitzell jfitzell@gmail.com:
Hi Sean,
Not sure... I guess we either put the instVar on the abstract ServerAdaptor and ignore it on subclasses that don't support it or you just implement it on the Swazoo adaptor and we pull it up whenever we're ready to implement it elsewhere. I don't think it matters too much, so just do what's easiest. If the ListenerAdaptor is using HTTP internals direectly enough that it's easy, that would be a good reason to pull it up.
If you feel like chasing up Göran/Giovanni to see about extending Comanche to support it, though, that would be awesome!
And, yes, it would be nice to have support for it in the control panel if you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
I'd probably put a String (preferably '0.0.0.0' and not '*') in the server adapter and do all the conversion and adaptation there. If the adapter doesn't support it then just do nothing. It would be nice if the status string would reflect the interface the server is listening on.
I was going to make that status string change.
So the consensus is to use '0.0.0.0' to represent all interfaces?
On Tue, Apr 20, 2010 at 6:16 PM, Sean Allen sean@monkeysnatchbanana.comwrote:
On Tue, Apr 20, 2010 at 12:13 PM, Philippe Marschall philippe.marschall@gmail.com wrote:
2010/4/20 Julian Fitzell jfitzell@gmail.com:
Hi Sean,
Not sure... I guess we either put the instVar on the abstract
ServerAdaptor
and ignore it on subclasses that don't support it or you just implement
it
on the Swazoo adaptor and we pull it up whenever we're ready to
implement it
elsewhere. I don't think it matters too much, so just do what's easiest.
If
the ListenerAdaptor is using HTTP internals direectly enough that it's
easy,
that would be a good reason to pull it up.
If you feel like chasing up Göran/Giovanni to see about extending
Comanche
to support it, though, that would be awesome!
And, yes, it would be nice to have support for it in the control panel
if
you don't mind. Just default to 0.0.0.0 on creation and add a command to change it I guess?
I'd probably put a String (preferably '0.0.0.0' and not '*') in the server adapter and do all the conversion and adaptation there. If the adapter doesn't support it then just do nothing. It would be nice if the status string would reflect the interface the server is listening on.
I was going to make that status string change.
So the consensus is to use '0.0.0.0' to represent all interfaces?
That is the standard way to represent all interfaces (at least in the *nix world).
And #listenOn:backlogSize:interface: happily accepts it. Does Swazoo not work with that value... I actually thought I tested it at one point. But in any case, if we're storing a string, yes, I think we should us '0.0.0.0'. Swazoo can either be fixed if it doesn't work with that or its adaptor can convert to '*'.
Julian
I was going to make that status string change.
So the consensus is to use '0.0.0.0' to represent all interfaces?
That is the standard way to represent all interfaces (at least in the *nix world).
And #listenOn:backlogSize:interface: happily accepts it. Does Swazoo not work with that value... I actually thought I tested it at one point. But in any case, if we're storing a string, yes, I think we should us '0.0.0.0'. Swazoo can either be fixed if it doesn't work with that or its adaptor can convert to '*'.
0.0.0.0 works with swazoo.
seaside@lists.squeakfoundation.org
-
Julian Fitzell -
Philippe Marschall -
Pierce Ng -
radoslav hodnicak -
Sean Allen