Lua Scripting Engine


#1

Lua is a nonstandard scripting language for web/API development, which is at the center of the Exosite’s web/API development interface. Please support at least one standard language: Ruby, Python, Node, or even Perl or PHP.


#2

Hi @atp,

Thanks for posting! This is a topic that we have considered internally. We are continuing to make improvements to our scripting system, but we have hesitated expanding our system in this specific way. I will try to explain why in this post.

In building Murano to be an execution environment for our customers to launch connected products and services, we are finding ourselves being careful to not conflate Murano’s Webservice and Solution Application features with a server environment made for web development. It is specifically not our intent to replace the best languages/environments for web/API development, embedded development, or mobile development. We are instead to focusing on the overarching orchestration between these dimensions of IoT, and to simplify the workflow for our customers. Instead of having to know all the specific languages/environments, we want our customers to build their IoT solutions by only learning about how to orchestrate Murano and its components.

We understand that this typically is a tradeoff between operational costs and the size of a development team vs. an aggressive development learning curve with non-standard tools. Making this learning curve as manageable as possible is my goal as a Support Specialist and is part of why this forum is here.

The fact is that today, if you want to your IoT Solution to have many connected features on Murano, you will have to write Lua code. This is is because our scripting environment has the means to interact with all Murano services and is either acting like the bridge or glue between Murano’s components. Our plan for Murano is to reduce the level of Lua’s involvement in Murano by enable services to talk to each other directly without being handled explicitly in Lua Event Handlers.

This is a topic that we are continuing to explore. The more you can tell us about your experience, the better we can make our Product fit your needs.

In the meantime, what specific challenges are you having with Lua? There may be a chance that I can help.

-Martin


#3

Martin,

I am posting in the Feature Requests category. As you say, “Do you know better than us? Of course you do, that’s why you’re here!” I am asking for an improvement in your customer experience and you took a lengthy way of saying you have decided against making your customer experience better. I made my post to encourage you to change your mind, and I am hopeful you will listen.


#4

@atp

It is clear that the open and conversational spirit of my last post, that I had thought I communicated, did not come through. It also sounds like the verbosity of my post contributed to that failing. To be clear, I have no handbook nor policy to communicate. I am here to have a conversation with you about your experience using Exosite’s products. It would be naive to think that every customer will have a perfectly positive experience, but I can work to make that group the largest majority possible.

It is also not feasible for us to build into the product every feature request a customer asks of us, but it would be foolish for us to close our ears to what our customers have to say. That is why I tried to communicate our current thought process and to firmly indicate that this is not a topic that is closed.

Your frustration with the Exosite’s scripting Lua environment is painfully clear. What specifically are you having trouble with? Absolutely Lua is not a standard web technology, what challenges is that fact creating for you? What problems would be solved for you by using a more popular scripting language?

Here to listen,
-Martin


#5

Thank you for your reply. Thanks also for acknowledging my request.

What problems would be solved for you by using a more popular scripting language?

This is self-evident. Buggy, inefficient, poorly-written code; availability of libraries; sharing of code; developer tooling; DevOps tooling; communication among developers; context-switching; longer development cycles; time wasted; $$$ wasted.

This is clearly not a desirable situation.