[MLB-WIRELESS] seeing connected nodes

[Steven Haigh]

On 06/08/2007, at 3:13 PM, Jason Hecker wrote:
>> Are there any plans for bring this back?  I assume there are  
>> technical
>> limitations.
>
> Ohhh, this sort of thing takes time.  I am sure someone can code it up
> over the course of a few evenings.

Probably. I'll set a bit of background history to explain what the  
changes are and why they've been made - as this can probably all be  
blamed on me ;)

The last revision of the wireless.org.au server was based on Fedora  
Core 4. This has a life-span for security updates etc of about 12  
months. After that, there are no security updates, no updates, no  
nothing. The advantage of this however is that mapserver RPMs were  
available for this distro! The down side about all this however is  
that it locked us into certain library version and packages that we  
really needed to upgrade to keep the system stable and secure.

The new server revision is built upon CentOS 5. CentOS is the  
community edition of RedHat Enterprise Linux (RHEL). The CentOS team  
take the source RPMs that RHEL uses and rebuilds them into a  
distribution - and in the process, change all references of RHEL to  
CentOS for legal reasons. The RHEL support timeframe for security  
updates and maintenance is 5 years. From my point of view, this is  
excellent - as we have 5 years to plan our next updates in a worst  
case scenario. The upgrade path between revisions of RHEL is  
excellent. The path is well tested on release, and is well supported.  
This means I don't need to rebuild the entire server every time we  
need to upgrade the OS.

Where this turns bad is that to make this all work correctly, we need  
to stick to packages in the RHEL or well supported software repos  
(such as RPMForge). As you guessed it, mapserver doesn't have any  
RPMs in either RHEL or RPMForge - so it needs to be built from  
source. Now to make sure we keep the server clean and crud free (ie I  
don't want to rebuild it in 12 months time!), I've asked the dev guys  
to put all the mapserver stuff in the common melbwireless home  
directory. I've also suggested that the mapserver binary be built as  
a static binary - so upgrades to server libraries will not cause the  
mapserver to break. I guess my aim is to separate system stability  
from mapserver stability and keep them both running under most  
situations. This is pretty difficult, as mapserver is not the easiest  
application to build. It has a lot of dependancies, and a lot of  
twists and turns to get where we want.

There are a number of pros and cons about using google maps for the  
node maps.
	Google maps:
+) CPU/bandwidth requirements are shipped to google.
+) Mapping data is freely updated (we don't have to pay!)
+) It's very feature rich
-) We lose existing feature sets
-) Development time increases greatly

	Mapserver:
+) We get full control over map appearances
+) We can do overlays for linking data
+) It should just work with existing site code
-) We have to try to acquire updated mapping data
-) mapserver is a pain to build and update
-) Very time consuming to get right

This is my insight into the whole maps issue. Feel free to ask any  
questions :)

--
Steven Haigh

Email: netwiz at crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9017 0597 - 0404 087 474