cancel
Showing results for 
Search instead for 
Did you mean: 

I'm not a programming wizard but...

Getting noticed

I'm not a programming wizard but...

This might seem like a stupid question but if mac addresses have traditionally been written in the following three formats:

 

1111.2222.3333

11-11-22-22-33-33

11:11:22:22:33:33

 

...why would you choose format 11:11:22:22:33:33 for your JSON output when ":" is a delimiter in JSON but "-" and "." are not?  They picked the worst of the three choices available.

 

I know that Python has a JSON parser but not everybody uses Python all of the time.  When I want something quickly I use command line curl and simple command line parsing techniques and it has worked very well for me until I run into this kind of stuff.  Then everything gets twisted into a pretzel.

 

5 REPLIES 5
Kind of a big deal

Re: I'm not a programming wizard but...

If you are going to use that argument you would say you can't use "-" because someone will interpret it as subtraction and you can't use "." because someone will interpret it as a decimal point.

Getting noticed

Re: I'm not a programming wizard but...


@PhilipDAth wrote:

If you are going to use that argument you would say you can't use "-" because someone will interpret it as subtraction and you can't use "." because someone will interpret it as a decimal point.


It's easy to distinguish text from number in JSON isn't it?  For instance a VLAN looks like this "blah":30.  Not even considering the fact that it's not enclosed in quotes I already know that 30 is a number and not a string because I know that VLANs are what I asked for and VLANs are what I received.  When I parse JSON from the command line I store it in the variable type of my choosing.  II'm just saying that if there's a choice to avoid a special character in a string (and there clearly is with the representation of a mac address) then why not make the best choice possible (or at least avoid the worst choice possible)?  With "." and "-" characters in numbers there really isn't a practical choice to make.  By using a delimiter in a string it turns an extremely simple parsing task into an extremely difficult parsing task without adding any value.  How is 11:22:33:44:55:66 better than 11-22-33-44-55-66 or 1122.3344.5566?  At the end of the day all three are strings and should be enclosed in quotes in JSON.  None of them would be confused with a number by a person requesting them because that person should clearly understand what a mac address is and how it should be processed.

Getting noticed

Re: I'm not a programming wizard but...

The use of the colon delimiter has been the main format since time immemorial and is even known as 'classic Format' and on some systems is the only recognised format for a mac address (I had the joys of working on a mainly IOS & CatOS network that used different formats and tracking devices across this network was irritating.)

In the past I have encountered reporting systems that only recognise the colon formatted MAC address.

So the answer is because that's essentially the default format.

Getting noticed

Re: I'm not a programming wizard but...

I just ended up creating a small program using Visual Basic that transforms all of the mac addresses from the 11:22:33:44:55:66 format to the 11-22-33-44-55-66 format after the JSON file download is complete.  Took me all of about 15 minutes to build.  Adds about 1 seconds of time to my process.  Makes the data WAY easier to work with when I need to work with it on the fly.

Highlighted
Getting noticed

Re: I'm not a programming wizard but...

Yeah it ended up the only way as I once created a floating palette for converting mac addresses between different formats as out team was getting really annoyed switching formats between IOS and CatOS formats.

In the end it expanded to include the ability to push various mac addresses to the clipboard (our Fluke devices for example) and it saved a little time each day.

 

 

I really should do an updated version but I lost the resource file for creating the onscreen resources.

Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.