Closed bakerkj closed 7 years ago
I am a little reluctant to just pull that change in as it causes problems on the Flightaware side. What's the use case you need to support, so I can get this done right?
I didn't realize something like this would cause problems on the FA side. Is the risk that someone might have two systems online at once with the same identifier?
I had two use cases in mind.
1) I'd like to be able to move a piaware install from one system to another without loosing history on the FA side. So I'd hoped to carry the unique mac id from one machine to the next.
2) Some folks appear to be running different piaware instances (one for dump1090 the other for dump978 - so the stats show up separately). I was hoping to try that out on one machine but need a different identifier for each piaware process.
Thanks!
No history will be lost when moving to another system, since it is retained under the old MAC address and a user account is allowed to claim multiple MAC addresses. Additionally user-specific stats will continue to include the summation of all MAC addresses associated with that account. You should focus on the user stats, rather than individual sites. There are hardware-specific performance trends that FlightAware would prefer to be able to differentiate separately.
@bovine I see. The data is certainly not lost, it is just associated with a previously used MAC address. I migrated my station from one MAC address to another a month or so ago and so I know how it looks. I guess I like the MAC address specific stats that I would hate for those to start from day zero again. But I can appreciate why FA might want to keep those separate. for performance trends and such.
There is temporary support for this starting in 3.2 and a longer term fix (breaking the dependency on MAC addresses entirely) is in progress.
Could you pull the overrideMac changes (53a29065f0d583b18bd745f784b7c3d43bb738f1) from the mutability/piaware branch to the flightaware branch?
Thanks!
-- Ken