I haven’t run into this problem yet but I can definitely see myself being pretty salty if I ever do. I only get a short amount of time per day to work on the GF, so if the great Cloud™ deems that it cannot process my job because it’s queue is full… well then we got a problem. So the ability to “preprocess” jobs would be at least a partial work around for some cases. They need to look into this quite seriously if the queue full thing becomes an issue that pops up more often.
I may be wrong, but I just think it’s a dead end. Besides, it is almost never an issue, and we’re not even sure what the problem was in this case. It may have had nothing to do with actually being overloaded.
I agree. Probably won’t happen. But eventually they NEED to look at allowing offline use of the machine. One of the (admittedly many) selling points when I went to buy the GF was that they had said they were going to open source it so people could write software for it that wouldn’t keep it tied to the cloud. I just don’t want to wait until it becomes necessary for that to happen before it does happen. No matter how much we want to think otherwise, companies pop up and die often. And hardware that is tied to a service with those companies becomes a boat anchor (I did NOT say paperweight, people… I didn’t. ) Just look at all of the 3rd party NEST hardware that relied on NEST’s cloud service integration. Once google bought them and got rid of that cloud service… POOF. Every one of those devices became a pretty decoration for people to sit on an end table and wonder where their money went. Not to mention the companies that lost revenue streams practically overnight. Things happen and we don’t want to be suddenly sitting on the outside looking in, wondering if someone is going to be able to successfully hack the hardware to allow us to use GRBL or some such software.
No they don’t. You want them to, but that doesn’t mean they need to.
[“it” being the firmware, not the server side processing routines, so it’s kind of not what you want] They did. It’s on the forum. It’s hard to search for it, but it’s out there… it just came up recently, Jules produced the link from the ether, I think. Hunt around if you haven’t seen it.
True, but this wouldn’t be GF’s problem. Companies aren’t your friends, they don’t owe you much of anything. If GF went out of business tomorrow, they wouldn’t be on the hook for anything, they don’t have a contract with us.
Some lawyer somewhere would probably take on the case and try to extract some cash out of the situation, but I wouldn’t hold my breath. You’re talking about a company that doesn’t feel like it needs to provide itemized invoices on repairs, you really think they’ll get too upset if we wish we could do stuff offline in the event of their demise?
Saving the instructions locally and reloading the same job would seem to be a good move. But decentralizing the processing of the job is just not something they seem interested in doing.
It’d be tricky to be sure it’ll work with changing materials: say you save the job to work with proofgrade maple, but they change their supplier, now your settings are all wrong. They aren’t terribly incentivized to do a lot to support non PG materials, as much as we might like it…
They want it to be a “push the button and it just works” kind of moment, and the more complex you make this the less it becomes that. Look at the wide array of people complaining about how it’s too complex as it is.
Again, I really do agree with you about caching, either locally or on their server, but I still wouldn’t hold my breath. (if it were me, I’d do it serverside and store a serialized array of the settings passed from the UI and a checksum of the uploaded SVG (after mods in the ui of course). I’d compare that info to recent jobs (say the last rolling month) and if I have a match just spit out the saved processed file. But I don’t work for GF so…)
Oh also, this. Yeah this is a detraction for some users, but the bulk of users don’t even think about it. That’s the best part: nothing to install, nothing to update, cross platform craziness. That’s a win for a huge swath of users and definitely for glowforge support.
Rando: “I have windows ME running on an overclocked atari 2600, do you have drivers for this?!”
Glowforge: “Get out of here with that driver business!”
It doesnt have to be locally saved, it can be cached server side and just redistributed to the unit that requested it.
They can just attach material type meta info to the saved job (which it will already have anyways), so if they are aware of a material change, just re-render. A couple lines of code maybe.
To a user the only difference the user should notice is that some of their renders are instant instead of taking a long time. I cant see how that breaks the ‘push the button and it just works’.
Its not really a problem that has a huge impact on my business personally, as I have other lasers. As someone who has good visibility to a large portion of their community, not only am I in a good place to make this suggestion, but also to inform those not familiar with the workings of these services, how things in the background work, and what potential solutions could be. Furthermore, once they are aware a better solution may exist, if they put their voices behind it, they could potentially influence glowforge to move in a direction that is in the best interest of everyone.
As long as an online app fits their business model and has more benefits than negatives, there doesn’t seem to be enough incentive to offer a stand-alone app that would need to be able to work on all the computing platforms that folks are using at the present moment.
I think @takitus’s solution seems reasonable, to at least be able to open stored jobs and print them locally. That seems like low overhead.
Still, I just take the online app for what it is worth. There will be issues, but it doesn’t come near close enough to erase all the benefits of having an app that is lightweight and doesn’t require me to do any local configuration.
But we have had this conversation before and it will go the same way at least for the short term.