Character length for the auto generated code is too long

[navinsubramani]

The RPC methods and Messages have nested folders, and the auto generated code has more chance to reach the maximum 255 character limit.

[navinsubramani]

@ccifra If you have suggestions of what names or folders can be removed or shortened, please comment here. I will look at updating the client and server scripting utility.

Some suggestion from my end:

1. Make the folder name of the class to be "service" instead making the folder with the class name which is too long.

2. Make all the VIs under the "RPC Methods" flat instead of nested folders. Given the name of the file is well name spaced, having them flat will not have any conflicts.

3. Make all the VIs under the "RPC messages" flat instead of one nested.

Note: This change might or might not support backward compatibility for the scripting tool.

[KarthikAbiram]

I agree, making them flat would be a good idea to avoid breaching the 255 length limit.

One thing to think about is, how would this change affect the previously built servers and is there any easy way to upgrade. Since we are retaining the VI naming and just reorganizing the folders, can a mass compile take care of relinking without any manual work?

[navinsubramani]

@KarthikAbiram Good point. Based on my previous discussion with @ccifra , given that this is a not a release product, we are not yet committed to support full backward compatibility. That said, we should define the servers and clients in such a way that they can be scripted with backward support.

I would upload a reference "server template" for sign-off before updating the scripts. The goal is that we align on a reference "server template" that has no character limit challenges, is backward compatible and user code is not disturbed because of scripting.

[chrisb2244]

What are the maximum path lengths on different platforms? Is this only a Windows problem? I found this link What is LabVIEW File Path Control/Constant Length Limit? which gives values around what I'd expect (I'm using Win10, and had an error with a path that turned out to be 275 characters) but I'm not sure if the maximum lengths on Mac/Linux/Linux-RT are more forgiving?

I ran into this problem in the "Save VI at Path" VI, but I can see there are a few more locations where files are saved during scripting (e.g the class, library). Would a change that checked all of these be appropriate, or would targeting specifically the "Save VI at Path" be preferable?

(I'm looking at trying to produce a more descriptive error for this case, given that it seems likely to potentially occur even if this issue is fixed and the paths are flattened in one way or another).

[KarthikAbiram]

Checking at all places would be ideal. Checking at Save VI be easier and would cover most common cases.

As per this stackexchange,

Linux has a maximum filename length of 255 characters for most filesystems (including EXT4), and a maximum path of 4096 characters.

So, while Windows has a path length limit of 255 characters, for Linux it is 4096 characters.

[navinsubramani]

Changes suggested for the template.docx

Please find the list of changes suggestion and the template service which has those changes in them. service.zip

This issue and maintaining this template can be dropped if everyone is interested in this type of template: https://github.com/ni/grpc-labview/pull/43

[twaltersp]

We have a complicated proto file (actually a library of them with includes) that we can't support due to path names. The error we are running into currently is related to creating the message data clusters. In this example the proto has a message with a number of other embedded messages. This leads LV to try to use the name: simian_public_sensor_model_Description_RadarModel_SensorFidelity_RaytracingConfig_AdaptiveSamplingParams_Target.

I've already tried to make the build path as short at possible but I can't modify the proto files since they are from a third party.

@navinsubramani @ccifra (mentioning directly since this is an old issue thread. I thought it was best to add here since it is related but wasn't sure this would get noticed).

[twaltersp]

I think the approach of directly using the names pulled from the proto files will be a challenge unless LV changes to support the full path that the OS provides (LV is limited to 256 char total path length I think).

Perhaps the scripted code approach needs to change to not use the direct name and instead have a map or other lookup function?