Re: xPL-Issue

[Tom Van den Panhuyzen <tomvdp@xxxxxxxxx>]

Happy to see this discussion!
The idea to include a hub in the xPL Library came because:
- there were quite often discussions about and/or problems with hubs (yes,
in the days before V3 too ;-)
- xPL Hal had a hub built-in
- it was technically quite easy to do
- it should always be up and running and be able to restart on crashes
- it is a core element of xPL just like the xPL library
- eases distribution
- the end-user doesn't need to know about hubs but can download and run any
xPL application
- at the time I wasn't aware there were so many other technologies used - I
thought most people were using services written in dot-net.

I think we are discussing 3 things at once in this thread: possible bugs in
V3, whether or not to seperate the hub from the library and the need for
mutexes.
1) V3-bugs
This is simple: there are none! Just kidding... Of course I would happily
investigate any bugs found. I am also one of the lucky few it seems where
xPL apps are running without troubles.
The currently raised problems are not V3 related I think (indirectly they
are):
- start order of services can influence hub-functionality: this is reported
a few times and I think it is related to the xPL Hal built-in hub starting
after a V3 hub. I think it makes xPL Hal crash (needs further
investigation)
- the xPL Monitor that stops showing messages (as reported by Ian): Ian,
did
you upgrade to the latest xPL Hal because this was once a known bug. The
monitor didn't send hbeats. Newer versions of the hub clean up their client
list, older versions didn't so kept on broadcasting packages even to dead
clients.
2) Seperate hub
Please add to this list of PROS / CONS.
PROS
- one seperate application responsible for hubbing
- can make use of the underlying OS' ability to restart on failure
- if the source is updated only one application must be updated
CONS
- it is a seperate and mandatory install
- it may confuse new users
- overkill in the scenario where a user is running xpl applications only
(not services)
- it must be distributed to end-users (versus to developers only)
I probably missed quite a few.
If we are going for a seperate hub implementation please note that the hub
that is now built-in into xPL Hal should be taken out, as this is - in my
opinion - a source of confusion.
I vote for the built-in functionality (surprise! ;-) As an end-user I
dislike applications that install services of which I do not know what they
are doing. And how do I know when to uninstall them ? Having a seperate
service running just to send a few packets around from port 3865 to other
ports is plain overkill.
3) Mutexes
The current implementation of V3 uses mutexes to detect when another V3 hub
goes down. They are surprisinly fast and reliable. Polling port 3865
availibilty could have been another option. There is also no reason why an
implementation on another platform could not use polling or even yet
another
way of detecting the need to start a hub. As long as the last xPL
application alive starts a hub. If there is some cross-platform standard
for
inter-process communication then it would perhaps be better to use that
(does it exist?). But for now the Windows dot-net implementation uses
mutexes to answer the question "must a hub be started".
Cheers,
Tom


[Non-text portions of this message have been removed]