Re: Re: Look ma, no hub?

[Mark Hindess <xpl@xxxxxxxxxxxxxxxxx>]

On 17 November 2005 at 20:32, "Ian Lowe" <ianlowe@xxxxxxx>
wrote:
>
> > Please explain what you can do with a hub that you couldn't do
> > perfectly well without one
>
> NO! *YOU* explain what is to be gained by making a drastic change
> to how things are done. The fact that a given OS supports a method
> doesn't mean that we should automatically adopt it: especially when
> the benefits in doing so seem pretty nebulous.

Wow.  Actually I wasn't asking anyone to adopt anything.  Just wondering
if it should be mandatory.  My original message on the subject made this
pretty clear with the first line:

Is it compulsory to have a hub?

> Jean Paul is asking us to leave things they they are, please, and you
> are asking for a change - justify your change, don't demand that users
> defend the status quo!

Fair point.  I never really meant to come across that way.

> > The application just has to:
>
> And what happens if an application *doesn't* do this? If you bind
> to 3865, then another app is broken, unless it also implements your
> method.

Then I wont run it or I'll change it (and will publish the changes if
the license permits it).

> There are a variety of linux implementations of xPL so far, and to my
> knowledge *none* of them use the SO_REUSEADDR option. To my mind that
> says that this is not a well known technique. Come to think of it, I'm
> struggling to think of any other situation where multiple instances of
> an application share a port in common usage.

I'm not sure it should matter if it is well known or not.  Developers
are usually pretty smart and can learn new things.  More important is
whether it works or is practical/beneficial.

However, just for information, it is most common with multicast
applications but I guess not many people are familiar with those either!
It is less common with broadcasts but works just as well on the many BSD
derived stacks that support it.  I'd be a little surprised if Windows
doesn't support it.

> > Personally I'd not have a problem requiring applications (and
hubs)
> > to perform this test on all platforms.
>
> Hmm. I would, because it's complexity for it's own sake!

Not for it's own sake.  It definitely does remove a point of failure.

> > Sorry to cause trouble here, but I think it is important to
justify
> > having single points of failure.

> Sorry Mark, but this is an argument that we have already had, and
> expended a lot of effort on - one of the most prolific developers
> walked away from the xPL project because of these same arguments
> sapping away at development effort.

I'm sorry to hear that.  However, I'm not sure the argument is the same.

> What the project needs is more useful applications, not more and
> more tinkering with the basics which already work!  Seriously - if
> you want to help the project, release cool new apps, interesting and
> useful home automation tools. The basic architecture is doing fine, it
> doesn't need more refining just yet.

I fully intend to write some applications. (In fact, I've been writing
some unit tests for my *hub* implementation this evening! ;-) Whether
the apps are useful to anyone but me really remains to be seen, but I
will release them even though this is not a trivial matter for me as I
mentioned before.

In order to write them and make them interoperate, I will ask a lot of
questions.  I hope that wont be a problem.  For my part, I hope that not
all my questions will cause this much trouble.

> As an aside, the SPOF argument also made an appearance during the
> Windows hub discussions. Despite the use of a windows mutex allowing
> multiple apps to act as a hub, therefore "removing a SPOF",
it
> actually caused apps to fail, fight over the xPL port, race conditions
> to emerge etc etc.

If I understand correctly, the Windows "alternative" still had
the
essential elements of a hub but simply spread the functionality around?
This sounds like a case of moving complexity from one application to
many.

The "alternative" I am proposing leaves no hub functionality
anywhere.
I believe I am removing complexity at runtime - possibly at the cost
of complexity at install time (or startup time if you like living
dangerously, which I do not).  To me, this type of trade off is not only
acceptable but also beneficial.

While I don't know the full details of the Windows "alternative",
it
doesn't seem the same to me.

> My opinion: It ain't broke. We don't need to fix it.

That sounds very final and I don't wish to upset anyone so I will
not continue this discussion even though it is useful to me.

I'm not intending to disturb the status quo.  I'm just to understand why
it is like it is.

I'm certainly not demanding any change.  Why would I when it matters
very little to me if the hub is mandatory or not?  My machines will
behave/interoperate the same way with other devices whether I run one or
not, so no one but me will know if I run one or not!

Regards,
Mark.