Re: Re: xPL Hubs

[Tom Van den Panhuyzen <tomvdp@xxxxxxxxx>]

So much focus on that hub!  :-)
It's ugly.  It shouldn't be there.  It should be hidden completely.

The hub's only purpose is to distribute incoming packages from port 3865 to
 any
xpl apps  active on  the pc.   It could  have been  implemented using a
complete
other  mechanism  of  inter-process  communication  than  via  broadcasting
 UDP
packages.  For  me  it  is  part  of  the  communication  layer,  it  is 
not an
application.

It would be cool to have monitors available via perfmon, webservices, mmc, 
etc.
But I  am not  sure the  hub is  the best  place where  you would plug
these in.
Wouldn't a monitor be an  xpl app like any other,  making use of the same 
inter
-process communication as all the other apps ?

I would like to  see the mechanism for  hub-enabling "on" by
default.   It makes
perfect sense to me that when an xpl app comes up, that it starts a hub if
there
is none.  It should be clear from the documentation that comes with the app
that
it is  hub-enabled.  In  fact, the  reverse is  true: every  app that is
not hub
-enabled should clearly indicate that it  will not work without an explicit
 hub
or without a hub-enabled app.

Why do some apps already  provide a hub ?  Because  they do not want to 
trouble
the user,  I suppose.   The only  way to  make this  even more transparant
is by
pushing developers to hub-enable their apps.

That a newly installed app stops your old hub because after a reboot it
couldn't
grab the port is a good thing: it means you have a new shiny hub and you
can get
rid of the old rusty one :-)

Agreed that a user must be able to disable the hub for whatever reason that
user
has...

There may be issues with  cross-platform compatibilities.  If you want  the
same
architecture  on  another  platform  (i.e.  something  called  xpllib 
providing
communication facilities)  and you  want it  to behave  the same,  then
maybe we
should opt for the lowest common denominator and not include hub 
functionality.

I admit that  I am not  on this list  long enough to  see the big 
architectural
picture. The modifications I  made to xpllib were  driven by a direct 
need: the
multiple IP issues,  security on an  internet connected pc,  missing
elements in
xpllib, integrating the hub into xpllib to solve a dependency issue, etc. 
While
I was  working on  this I  thought most  people would  use (or  move to)  a
.net
development environment  as this  xpllib is  targeted at  that environment
and I
have  not  seen an  xpllib  that was  not  targeting .net.  So  I thought 
these
modification would benefit the community as a whole.  But if there is  a
big mix
of platforms and technologies then that is not the case.

Regards,
Tom