Function Not Found

[Moors7]

Okay, for the very last time…

You put a function in your code.

If the function name is <= 12 characters, the device registers it and submits it to the cloud.

If the function name is >12 characters the device doesn’t register the function and it doesn’t get submitted to the cloud.

The cloud can only reach functions it knows of.

It knows of functions because the devices told them what they were.

If the device didn’t tell them a function exists, the cloud doesn’t know the function.

If you call a function from the cloud, the cloud must know said function.

If the cloud doesn’t know a function you’re trying to call, it will tell you so.

The message you get when the cloud doesn’t know a function is “function unknown”.

The cloud is ‘stupid’. If you don’t tell it something exists, it doesn’t know.

The device is the one who tells the cloud what does or doesn’t exist.

The device won’t tell the cloud your function exists if you don’t stick to the rules (<= 12).

Computers don’t make mistakes, humans do.

You CAN NOT check for a function in the cloud if the cloud doesn’t know it exists in the first place. Better yet, it doesn’t exists, because it broke the rules, and was thus not created.

I don’t care WHAT you put on the end of the URL, if it’s not there, you’re not going to find it. On that I must agree, that’s no rocket science if you ask me…

[johnwargo]

OK, for the very last time…

The cloud COULD check the length of the function it’s being asked to use and, if the length of the function name is more than 12 characters, it would know why it won’t be found and return a more useful response. That’s all I’m trying to say. Who cares how dumb the cloud is? Make it a little bit smarter. It’s still just a few extra lines of code to understand this problem better.

Why are you so opposed to making this more robust?

If it knows it’s too long, it will know it will never find it and can actually HELP the developer deliver a better implementation. All this did was make it harder to figure out what was wrong instead of simply telling me what the actual problem is. The problem is that my function name was too long and therefore wasn’t registered. The indication/indicator is that the function name could not be found. The latter indicator is not a good representation of the former.

I’m now officially sorry I ever even suggested something that would make the product better.

[johnwargo]

I am not missing the point. The folder not found error in DOS is accurate because the folder doesn’t exist. In my case, I made the function, the device ignores it, so it’s not that it’s not found - it’s there, I just used a name that’s too long. That’s a COMPLETELY different problem.

[Moors7]

First of all, I'm not opposed to improving anything, let that be clear. I just think this thread has gotten way more confusing than it ever needed to be.

The cloud cannot check for function length on the device, since it has to be the device who tells the cloud what is and isn't there.

@johnwargo

The folder not found error in DOS is accurate because the folder doesn't exist. In my case, I made the function, the device ignores it, so it's not that it's not found - it's there, I just used a name that's too long.

That's the thing, it ISN'T there, BECAUSE you used a name that's too long. It doesn't exist. "Function can't be found" is therefor a very appropriate response.

If what you're suggestion is an input check on the API, then yes, that wouldn't be a bad thing. But there's a multitude of reasons why a function can't be found, so you'd have to account for those as well.

Let's ask @dave to chime in on the possibilities of implementing this on the cloud side, as far as pro-active input checking goes. I'd then also suggest to add a note that mentiones:"you should really consider reading the docs", but that's my personal opinion.

Sorry if I gave you the feeling that suggestions are unwanted or that we're firmly opposed to any such ideas. I think a fair bit of this topic is based on misunderstandings, which I hope won't interfere with the intention of improving the platform. Suggestions like those are definitely welcome, and I genuinely hope you'll continue to make them in the future.

[ScruffR]

@johnwargo

I am not missing the point. The folder not found error in DOS is accurate because the folder doesn't exist. In my case, I made the function, the device ignores it, so it's not that it's not found

Yes you are.
Have a look at your URL and see the resemblence with a filesystem path.
Imagine you have a folder (with some executable in it) on your USB drive and you try to copy (or link) it to your HDD but this copy (or link) fails but you ignored the result of the copy/link action.
Later on you try to execute the supposedly copied/linked program - what would you expect to happen?

That is exactly what happens if your firmware function exposure fails. The endpoint had not come to exist (on the cloud side - which you are talking to)

[johnwargo]

No I’m not - please stop telling me I’m not understanding something. You have absolutely no way of knowing that. Just because you think I’m not understanding you doesn’t mean that I am. You’re ignoring my point and using what you think you know to say that I’m missing your point. That’s rude, inconsiderate, and disrespectful.

I understand URLs and File systems. I’ve been a professional software developer for more than 30 years and I’ve written 6 books on mobile development. I understand all of this.

I get it, I get the fact that the device never registered the function, therefore the cloud can’t find it. I’ve never, never ever argued that that wasn’t happening. What I’m saying, and you’re COMPLETELY ignoring it, is that there’s a way to tell that the function won’t be there and let the user know.

When DOS delivers a file not found or a folder not found error - it’s because it’s not there. When the Particle cloud delivers a function not found error, it’s not because the function’s not there, the function actually is there - it’s because it wasn’t ever registered. It’s there, it’s just that the cloud can’t see it. Yes, it feels like it’s not there, but to me, as I was toubleshooting this problem myself, it was not a clear error as everything I was seeing told me it was there. That’s why I’m suggesting, and not because I don’t understand something that’s been said here, is that it’s possible, and I’ve shown several ways already, to provide the developer with a more useful error message. Again, I promise you that my stupid little suggestion isn’t coming because I don’t understand you, I do understand what everyone is saying, I simply don’t agree it doesn’t need to be changed.

[AndyW]

I get the point @johnwargo is making. Will people please stop trying to talk him out of it.

The cloud knows damn well that if you try and access a function/variable with >12 characters in the name, it’s never going to work. Let’s have it impart that knowledge back to the caller.

All the other points people are making are technically accurate, but miss his central point, which is about making these things less arcane for users who stumble into this problem.

[Dave]

Hi @johnwargo,

Thanks for posting your experiences and feedback, it’s very valuable!

I agree that the error messages and hints you got from the API in this case were probably confusing, and could have been more helpful. As an engineer building tools like this, it’s critical that we accept and internalize feedback, especially when it challenges our assumptions about how something should behave! So, tl;dr; thanks! I agree that we can make the errors more helpful. I plan to bring this up with the team, and talk about how we can improve on our end.

There was a question mentioned, “Why doesn’t the cloud API just tell you a variable over 12 characters would never work?”. I wanted to share some backstory on that in case it’s interesting.

Your question is awesome, and the answer involves some assumptions I made, and limitations we had on the Core. The Spark Core had 20 KB of ram, about 4K of which was available to user apps. Registering variables and functions impacted that space, and they couldn’t be dynamically reserved like they are now (I hope?). So limiting the length to 12 bytes was a decision that happened in firmware for the Core, but wasn’t a constraint that needed to exist on the cloud.

I figured we wouldn’t have the same hardware limitations forever, and certainly people might make their own hardware, so the cloud didn’t worry about how long functions or variable names were, it would defer to the device itself to set those limitations. The device would be the source of truth. This is really convenient for someone building a giant distributed system, and it’s nice for being flexible, but it can be confusing if you don’t have that knowledge. I’ve also been caught at times by similar assumptions around our security model when I’m trying to call a function only to discover it’s on a device I don’t own, etc, etc.

Anyway, that’s all to say, thanks again for the awesome feedback, I love when people post stuff like this, and we’ll keep trying to make things better on our end.

Thanks!
David

[jvanier]

@johnwargo

Actually, the more I think about it - it's actually the compiler (the code verification process) that should be catching this.

Indeed! That a great idea: catch everything you can at compile time. I'll make a pull request with this.

[AndyW]

Dave, implicit limits are totally understandable, especially given the history.

Either enshrine them as absolute known constants or make them dependant on the version/capability of the protocol that is running/negotiated between the cloud and the device. However I don’t think it is certain that resources available on devices will always grow over time, think BLE endpoints etc,

So a fixed value of 12 is not a bad number, IMHO. Remember, some of us cut our teeth on systems where things had to be unique within 7 or 8 characters, and produced non-intuitive compiler messages (admittedly they were compile time errors, not runtime). But kids these days are used to variable names without limit, so if we are going to limit, let’s make it obvious and inviolable.

[jvanier]

A warning in this situation will be valuable for both beginners and experts. This discussion lead us to figure out that the best place for this warning is in the firmware build process, as opposed to the cloud server or the client (CLI).

The firmware compiler will now generate an error at compile time when a function or variable name is too long. This will be available in the next firmware release.

Give a compiler error for long names in Particle.variable/function

[ScruffR]

Just to be clear about this

@jvanier

The firmware compiler will now generate an error at compile time when a function or variable name is too long.

Which will only work if the length can be assessed at compile time - meaning string literals are used (which will be in most cases ;-))

[johnwargo]

Woohoo! That’s exactly what’s needed, let them know it won’t work.