From: Michael S. <mi...@st...> - 2011-12-27 04:47:50
|
I suspect the xPL hub implementation in MH is quite a bit out of spec. Also the xPL guys eventually issued the edict that no xPL application should contain a hub. So I'm left wondering if (we|I) should 1) bring the xPL hub implementation up to spec or 2) remove the hub implementation all together. What do y'all think? Sincerely, Michael |
From: Marc M. <ma...@me...> - 2011-12-27 09:06:23
|
On Mon, Dec 26, 2011 at 10:47:45PM -0600, Michael Stovenour wrote: > I suspect the xPL hub implementation in MH is quite a bit out of spec. Also > the xPL guys eventually issued the edict that no xPL application should > contain a hub. That should be a recommendation, at best :) > So I'm left wondering if (we|I) should > 1) bring the xPL hub > implementation up to spec or > 2) remove the hub implementation all together. I had to disable the hub right away since it didn't work for me. It would have been nice if it had worked but at the same time, it wasn't a hard requirement. In some way, I don't see a real reason for hub code to be inside mh when there is better maintained outside code that does the job fine. So I would actually lean towards #2 just because it's less work and the code doesn't seem necessary anyway. That said, if there is a reason for #1 and you feel like doing the work, don't let me stop you :) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Lieven H. <li...@li...> - 2011-12-27 13:00:30
|
Hello, Op 27-dec.-2011, om 10:06 heeft Marc MERLIN het volgende geschreven: > On Mon, Dec 26, 2011 at 10:47:45PM -0600, Michael Stovenour wrote: >> I suspect the xPL hub implementation in MH is quite a bit out of spec. Also >> the xPL guys eventually issued the edict that no xPL application should >> contain a hub. > > That should be a recommendation, at best :) > >> So I'm left wondering if (we|I) should >> 1) bring the xPL hub > implementation up to spec or >> 2) remove the hub implementation all together. > > I had to disable the hub right away since it didn't work for me. It > would have been nice if it had worked but at the same time, it wasn't a > hard requirement. > In some way, I don't see a real reason for hub code to be inside mh when > there is better maintained outside code that does the job fine. I agree with Marc, I don't see a reason for MH to implement hub functionality. I'm also using an external hub application and I disabled the internal MH hub. Best regards, Lieven. |
From: Timothy S. <spa...@ic...> - 2011-12-28 12:07:28
|
Hi, I like the fact that MH has a xPL (and xAP) hub and would like to see it stay in place and updated as necessary. Because it can be disabled, I think all can be happy if someone wants to use an external hub application; personally, I don't want to find another windows app just to be a xPL hub. -----Original Message----- From: Lieven Hollevoet [mailto:li...@li...] Sent: Tuesday, December 27, 2011 8:01 AM To: The main list for the MisterHouse home automation program Subject: Re: [mh] xPL Hub: Repair or Rip Out? Hello, Op 27-dec.-2011, om 10:06 heeft Marc MERLIN het volgende geschreven: > On Mon, Dec 26, 2011 at 10:47:45PM -0600, Michael Stovenour wrote: >> I suspect the xPL hub implementation in MH is quite a bit out of >> spec. Also the xPL guys eventually issued the edict that no xPL >> application should contain a hub. > > That should be a recommendation, at best :) > >> So I'm left wondering if (we|I) should >> 1) bring the xPL hub > implementation up to spec or >> 2) remove the hub implementation all together. > > I had to disable the hub right away since it didn't work for me. It > would have been nice if it had worked but at the same time, it wasn't > a hard requirement. > In some way, I don't see a real reason for hub code to be inside mh > when there is better maintained outside code that does the job fine. I agree with Marc, I don't see a reason for MH to implement hub functionality. I'm also using an external hub application and I disabled the internal MH hub. Best regards, Lieven. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Michael S. <mi...@st...> - 2012-01-04 03:35:35
|
On Wednesday, December 28, 2011 at 6:07 AM -0600, Timothy Spaulding wrote: >Hi, > >I like the fact that MH has a xPL (and xAP) hub and would like to see it stay in place and updated as necessary. > >Because it can be disabled, I think all can be happy if someone wants to use an external hub application; personally, I don't want to find another windows app just to be a xPL hub. > I agree that it is nice to have a working hub for kicking the tires, but.... it looks like quite a bit of work to fully fix it and only one vote in favor. For now I at least made it work somewhat and I resisted the urge to spit out a big warning if someone enables it. I also updated mh.ini defaulting the hubs (both of them) to the inactive state. The primary remaining problem, that I've discovered so far, is that the hub never times out dead clients. This is a problem because many of the non-MH xPL applications let the IP stack pick a random port when starting. So if you use the MH xPL hub and restart an xPL application, the application will pick a new UDP port and the hub will merrily send all xPL messages to the old port as well as the new port. At best MH will slowly degrade over a period of time consuming lots of CPU rebroadcasting thousands of xPL messages to non-existent clients; luckily these messages will not actually make it out on the wire. If anyone is curious the hub specification is here: http://xplproject.org.uk/wiki/index.php?title=XPL_hubs_specification MH is missing the functionality in section 3.4. Also most modern xPL hubs delete a client when receiving a hbeat.end message without waiting for the timeout. Sincerely, Michael |
From: Marc M. <ma...@me...> - 2012-01-04 11:13:53
|
On Tue, Jan 03, 2012 at 09:35:23PM -0600, Michael Stovenour wrote: > On Wednesday, December 28, 2011 at 6:07 AM -0600, Timothy Spaulding wrote: > >Hi, > > > >I like the fact that MH has a xPL (and xAP) hub and would like to see it > stay in place and updated as necessary. > > > >Because it can be disabled, I think all can be happy if someone wants to > use an external hub application; personally, I don't want to find another > windows app just to be a xPL hub. > > > I agree that it is nice to have a working hub for kicking the tires, but.... > it looks like quite a bit of work to fully fix it and only one vote in > favor. For now I at least made it work somewhat and I resisted the urge to > spit out a big warning if someone enables it. I also updated mh.ini > defaulting the hubs (both of them) to the inactive state. Actually I think outputting a big warning is a great idea. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |