You are here

Maximum Column Widths

17 posts / 0 new
Last post
AB8XA
Maximum Column Widths

Some have sentence-long node names, DHCP reservation names, and Service names. It makes for a wide mesh status screen, resulting in horizontal scrolling on some small displays.

Would it be possible to truncate those, with column width adjustable in Advanced Settings... perhaps with a default of 25 characters or so?

Something like:

Node Name:
XXXXX-NanoStation-M2-off N-Fairfield-Rd-in-Beavercreek-Ohio.local.mesh
XXXXX-NanoStation-M2-off N-Fairfield-Rd...

Service Name:
Join our weekly MeshChat conference every Wednesday at 800 PM
Join our weekly MeshChat conference ever...

 

AE6XE
AE6XE's picture
Yes, this is possible.   Let

Yes, this is possible.   Let me investigate, there might be a relatively low effort way to do this. 

AA7AU
AA7AU's picture
When/If you do

In the interest of addressing duplicates (across the mesh) in DHCP Address Reservations, how about adding a single text line above "DHCP Address Reservations" in the /cgi-bin/ports page which might read something like this: " * Note: should be unique name within mesh". That would get a bit more info in front of those making the choice of (new/updated) DHCP names.

Just a thought, Thanks,
- Don - AA7AU

AA7AU
AA7AU's picture
Already addressed

Guess I need to do more research before posting suggestions here. Turns out duplicate DHCP hostnames have already been addressed in the nightly builds:
https://github.com/aredn/aredn_ar71xx/issues/216

- Don - AA7AU

 

AB8XA
Thanks, Joe!

Thanks, Joe!

al0y
al0y's picture
while we at it

While we at it, can I also request the all entries in the "reserved hosts" should have the Callsign prefixed? 
It makes no sense (and it's annoying sometimes) to see hostnames like: pbx.local.mesh, mail.local.mesh ... I can understand that it could be a general host name generated by a pre-built Pi image ... but if two people on the network do the same, it's a mess.

If the software can force appending "AL0Y-" to the beginning of the hostname and convert it to al0y-pbx.local.mesh for example, it will be great and will solve a lot of problems.
 

AE6XE
AE6XE's picture
AL0Y,  this idea has come up

AL0Y,  this idea has come up a few times in the past.  Let's get this one on the github issues list -- I suspect there could be some discussion about how this is done.   It might have overlap with the "/" usage for international operation as well, an existing issue submitted.

AA7AU
AA7AU's picture
I understand the frustration

I understand the frustration with the lack of discipline and/or consideration for others that evidences itself in these types of non-unique service names across whatever mesh one might be connected to (another one of the reasons on my Idhao Mesh Island we won't use tunnels to other meshes). However I fear that the approach to solving it with heavy-handed firmware "legislation" may very will end up with lots of unintended consequences. I hope this gets thought out *completely* before rushing to try to "solve stupid".

As far as my little Mesh Island up in Idaho, a mandated renaming (or extnded naming) of mesh services would really screw up some stuff already in place. We don't worry about bozos advertising pbx.local.mesh because the users themselves are already disciplined and self-policing. I would likely hold back and not implement whatever firmware release it is that attempts to enforce this, at least until I had the time and energy to thoroughly go thru all the other stuff which tries to use these mesh services. I really hope there is a better solution found, or a way to control those outliers. Maybe a dup-check before DNS accepts the offered service ... or whatever. We're Hams, we're not Part 15 operators, we shouldn't have these problems.

Personally, I would love to see s "whitelist"/ "blacklist" ability to control which nodes/IP#s connect to my node but that is likely a major task.

Good luck with this hot potato,

- Don - AA7AU
 

KD2EVR
KD2EVR's picture
A good compromise might be to

A good compromise might be to present intelligent defaults/pre-populated fields.  Something a little like the way advertised service links are "built".  

AB8XA
! legislation

Don, giving those of us with small mobile and portable screens relief from wide pages is NOT "heavy-handed firmware "legislation." If the column width is adjustable, those in your Idaho island can set them as wide as you like.

AA7AU
AA7AU's picture
Sorry

Sorry, I guess I mis-communicated. I was NOT referring to column width issues whatsoever.

I am all for light-weight manageable/usable output and would love to eventually see some sort of  custom CSS type approach being available for the various mesh screens to give even finer control to the end user.

I was (speaking for myself and not for all of Idaho) referring to the possible suggestion to mandate longer compound service names, implemented in the firmware, to include callsigns or whatever on all advertised services. Due to service naming "abuse" (which is caused by ignorance and/or lack of consideration) this topic quickly becomes a contentious issue. I would advocate for education over the other approach.

Sorry for the confusion,
- Don - AA7AU   (an island dweller)
 

AA7AU
AA7AU's picture
A follow-up idea

To the extent that using "bad" service names reflects lack of understanding of the issues involved, perhaps a "How to best setup services" write-up here someplace on this site might help (I have looked and not found anything like that). One could even send a link to URL for such a write-up to folks who are using less-than-optimumly named services as a useable "hint".

I have wondered why there is apparently no Wiki type of setup for AREDN as having one place to find the latest/most-current info by topic/device/usage would be far better than trying to drag thru all the several years of posts here in the forums.

Just a thought - definitely NOT a complaint - thanks for all that the team does,
- Don - AA7AU

K5DLQ
K5DLQ's picture
@Don, have you seen the new

@Don, have you seen the new online docs?   (Under the DOCS menu on the website)
https://arednmesh.readthedocs.io/en/latest/
 

AE6XE
AE6XE's picture
Also,  any suggestions to

Also,  any suggestions to update or correct the documentation can be made to:  

https://github.com/aredn/documentation/issues

AA7AU
AA7AU's picture
Wow

Darryl/Joe: thanks for the quick follow-up to my post. This is *terrific*. No, I had not noticed it before. Well done and nicely packaged, in a form that would seem to be easy to keep current. I feel sorta bad for not noticing it.

What a treat to start the new year going forward for 2019! I haven't looked for a section on naming services yet, but now I know where to direct my feedback.

Thank you so much for all that you do,
- Don - AA7AU


edited 7-Jan to add: Thank you, Steve Lewis, KC0EUW - well done!

K5DLQ
K5DLQ's picture
+1

+1
Thank Steve Lewis, KC0EUW.   This is largely started and produced by him.  He's made a fantastic contribution to AREDN.

K6AH
K6AH's picture
+1

+1

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer