Do we know what release will have variable support?

I've been getting into customizing various aspects of my printer, and in a few scenarios variables are pretty much mandatory.

Are we looking at 3.2, 3.3, something even further out?

@gloomyandy said in no keep alive support?:

I'm not sure if DWC makes use of this feature but I suspect it may for some of the more frequent operations.

DWC/Chrome is asking for it. request header "Connection: keep-alive"
however the server always responds with a response header "Connection: close".

I have yet to see it allow keep-alive.

(for more details see: https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L448).

If i read that properly the code already has everything it needs to handle persistent connections, as it's inspecting the request headers in HttpResponder::SendJsonResponse

see line 986 through 999
https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L986

however when HttpResponder::SendJsonResponse calls HttpResponder::GetJsonResponse the first thing it does it set keepOpen = false;

https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L450

so the if statement that starts on 987 never gets run.

assuming i'm reading this properly, I haven't worked with c/c++ in almost 20 years.

I personally prefer to make things as simple as possible, and can't get much simpler than a hard wired touch screen.

if anything was to change, I'd vote for larger screen higher resolution screen option, Perhaps a 10" model.

I'm not sure what the cost would be but you can find a lot of 10" 1080p tablets today for under $100 USD.

@deckingman said in Whats does the roadmap look like for variables?:

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

I'm a developer by trade i think you need to consider a few things!

• Just because a piece of software functionality worked on one piece of hardware doesn't mean it will work on another with different architecture.
• I'd be willing to bet their are substantially more v2 boards in the wild than v3, so the wants and needs of v2 users will most likely take precedence.
• Some of the new features might make it easier to fix outstanding issues. On several occasions i have done this, mainly because it involved rewriting a sub system from scratch.
• From what I can tell, your use case is very much and edge case, so you should expect issues imo.

@deckingman said in Whats does the roadmap look like for variables?:

I'll bear that in mind but I suspect anyone who bought the latest generation of a product such as a 'phone would be somewhat miffed if many of the bundled apps (which worked on the previous version and are still bundled with the new version), didn't work.

The underlying hardware architecture for phones hasn't changed in a long time though. I think almost every phone on the market is based on ARM. If the next generation was x86 based, people would go mad because all kinds of things would break.

If people don't want to deal with issue, then they shouldn't be an early adopter. Doesn't matter if it's phones, sbcs, tvs, cars etc.

@CaLviNx said in Whats does the roadmap look like for variables?:

As a user I expect the "evolution" equipment (that I have paid for) to "fit for purpose" its not as if the end user is forcing the supplier into supply, but the supplier does use the "evolution" features to entice existing (and new) users into making a purchase.

No one is forcing you to buy it, and it's on you if you fall for a sales pitch, or can't control your consumerism!

@gloomyandy said in no keep alive support?:

I'm not sure if DWC makes use of this feature but I suspect it may for some of the more frequent operations.

DWC/Chrome is asking for it. request header "Connection: keep-alive"
however the server always responds with a response header "Connection: close".

I have yet to see it allow keep-alive.

(for more details see: https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L448).

If i read that properly the code already has everything it needs to handle persistent connections, as it's inspecting the request headers in HttpResponder::SendJsonResponse

see line 986 through 999
https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L986

however when HttpResponder::SendJsonResponse calls HttpResponder::GetJsonResponse the first thing it does it set keepOpen = false;

https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L450

so the if statement that starts on 987 never gets run.

assuming i'm reading this properly, I haven't worked with c/c++ in almost 20 years.

@gloomyandy on most servers you can enable/disable it. You can alsoalso set a timeout in seconds. for example if the timeout is set to 1 second., and a client isn't sending at least 1 request per second, the connection gets closed and the client will ned to open a new one.

take a look at this.
https://blog.catchpoint.com/2010/09/17/anatomyhttp/
what we have now is a "Simple HTTP Transaction" what would be better imo, is "Persistent HTTP Transactions"

keep in mind thats right now dwc is doing several Simple HTTP Transactions per second per client depending on what you have the update interval set to.

No comment from anyone?

I've bee playing with the rest api, and I've noticed the webserver doesn't support keep-alive as its returning the Connection: close header.

as you can see in curl time info, the vast majority of the time is spent in the actual connection process.

How come keep-alive isn't supported? I'd assume its would drastically speed up rest request and require less processing on the server side.

{'queue': 0.0001900196075439453, 'namelookup': 0.000247, 'connect': 0.07614, 'appconnect': 0.0, 'pretransfer': 0.076735, 'starttransfer': 0.095732, 'total': 0.098032, 'redirect': 0.0}
{'queue': 0.00019788742065429688, 'namelookup': 0.000242, 'connect': 0.080443, 'appconnect': 0.0, 'pretransfer': 0.080974, 'starttransfer': 0.115489, 'total': 0.117788, 'redirect': 0.0}
{'queue': 0.00019812583923339844, 'namelookup': 0.000247, 'connect': 0.014784, 'appconnect': 0.0, 'pretransfer': 0.015313, 'starttransfer': 0.033031, 'total': 0.035209, 'redirect': 0.0}
{'queue': 0.0004220008850097656, 'namelookup': 0.000324, 'connect': 0.088544, 'appconnect': 0.0, 'pretransfer': 0.089263, 'starttransfer': 0.107743, 'total': 0.110958, 'redirect': 0.0}
{'queue': 0.0003349781036376953, 'namelookup': 0.000368, 'connect': 0.090079, 'appconnect': 0.0, 'pretransfer': 0.090792, 'starttransfer': 0.108313, 'total': 0.112317, 'redirect': 0.0}
{'queue': 0.00047397613525390625, 'namelookup': 0.000356, 'connect': 0.012627, 'appconnect': 0.0, 'pretransfer': 0.013447, 'starttransfer': 0.030731, 'total': 0.034989, 'redirect': 0.0}
{'queue': 0.00031685829162597656, 'namelookup': 0.000307, 'connect': 0.018068, 'appconnect': 0.0, 'pretransfer': 0.01898, 'starttransfer': 0.033064, 'total': 0.035829, 'redirect': 0.0}
{'queue': 0.00025391578674316406, 'namelookup': 0.000283, 'connect': 0.011788, 'appconnect': 0.0, 'pretransfer': 0.012383, 'starttransfer': 0.052768, 'total': 0.056302, 'redirect': 0.0}
{'queue': 0.0002541542053222656, 'namelookup': 0.000282, 'connect': 0.021589, 'appconnect': 0.0, 'pretransfer': 0.022161, 'starttransfer': 0.034674, 'total': 0.037374, 'redirect': 0.0}
{'queue': 0.0002028942108154297, 'namelookup': 0.000247, 'connect': 0.017565, 'appconnect': 0.0, 'pretransfer': 0.018093, 'starttransfer': 0.035114, 'total': 0.037305, 'redirect': 0.0}

@CaLviNx said in Whats does the roadmap look like for variables?:

I must thank you for this post, it has reminded me why it is folly to try hold a cognitive discussion with a fool who thinks he is clever, as it is akin to playing chess with a pigeon, because no matter how good you are at chess, said pigeon is still going to shit on the board and strut around like it won anyway.

And on that note any further input from myself is pointless.

I wouldn't call you a pigeon, but if that's how you see yourself then so be it!

@deckingman said in Whats does the roadmap look like for variables?:

But as you profess to being (quote) "a developer by trade" your statement is a classic excuse that I see is becoming more and more prevalent among your profession. Personally I find it insulting to blame purchasers of products for what is essentially inexcusably bad conduct on the part of the person who has not done his/her job properly.

You can be insulted all you want but your comments imo show a lack of understanding with regards to the subject at hand. No developer, team of developers, company, or even massive tech industry giant can ensure no user ever has issues, specially when you are talking about non trivial applications.

The number of potential issues grows almost exponentially with the complexity of the software. Thus, project/product managers usually focus on bugs/features/issues that are of a concern to the majority of the user/revenue base.

For example what would you fix first? A bug related to one users who is running a 15 year networking card, or a bug (that's not your fault) that affects several thousand people because Microsoft decided to make a change and then push it out in an automatic update without telling down stream companies/developers/manufactures?

Now scale that up to hundreds or thousands of bugs and feature requests.

If you had a trade person in to undertake some work which turned out to be sub-standard, would you find it an acceptable excuse if that trade person turned around and told you that he/she hadn't been in business or hadn't been doing the job for long, therefore it's your fault for being an early adopter?

I personally wouldn't find myself in that situation as i can do most trade stuff myself. Plumbing, electrical, carpentry, care repair etc. Even if i didn't have the skills I do, i'd still check a contractor's credentials.

@CaLviNx said in Whats does the roadmap look like for variables?:

As a user I expect the "evolution" equipment (that I have paid for) to "fit for purpose" its not as if the end user is forcing the supplier into supply, but the supplier does use the "evolution" features to entice existing (and new) users into making a purchase.

No one is forcing you to buy it, and it's on you if you fall for a sales pitch, or can't control your consumerism!

@deckingman said in Whats does the roadmap look like for variables?:

I'll bear that in mind but I suspect anyone who bought the latest generation of a product such as a 'phone would be somewhat miffed if many of the bundled apps (which worked on the previous version and are still bundled with the new version), didn't work.

The underlying hardware architecture for phones hasn't changed in a long time though. I think almost every phone on the market is based on ARM. If the next generation was x86 based, people would go mad because all kinds of things would break.

If people don't want to deal with issue, then they shouldn't be an early adopter. Doesn't matter if it's phones, sbcs, tvs, cars etc.

@deckingman said in Whats does the roadmap look like for variables?:

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

I'm a developer by trade i think you need to consider a few things!

• Just because a piece of software functionality worked on one piece of hardware doesn't mean it will work on another with different architecture.
• I'd be willing to bet their are substantially more v2 boards in the wild than v3, so the wants and needs of v2 users will most likely take precedence.
• Some of the new features might make it easier to fix outstanding issues. On several occasions i have done this, mainly because it involved rewriting a sub system from scratch.
• From what I can tell, your use case is very much and edge case, so you should expect issues imo.

@arhi The firmware will run on the DUET 2 ETHERNET/WIFI already, so it doesn't need to be tied to the DUET 3 issues.