The functionality is a small screen with a timer and a few API calls to set the timer for you sometimes. $189 for a timer is not a lot of functionality for more than 1% of the annual salary of a minimum wage worker. You can get a full android phone for that much which has 10000x the functionality.
Super interesting you guys have been working on this since 2020 if I'm reading the post title correctly? Would love to know the iterations you've gone through.
It would be hard to count. Basically every customer we had on Release 1.0 was an iteration towards this. If you go to https://release.com it's there and we have many happy customers using it. There are definitely challenges with that business, however, that made us look for easier ways to get people using the platform we had built. People looking to do ephemeral environments have a lift to move their environment definitions into Release and it's a work effort that needs prioritization. Release.ai is built on the same platform and because AI frameworks are more turn key than bespoke software stacks companies have been building on, we believe Release.ai will be easier to adopt. In the long run AI applications and traditional web applications are going to merge and we think we're the platform that will do that in the long run. Long story short, hundreds of iterations.
This is amazing and a project I always thought about doing! Inspired by MUD servers back in the day that were open source and community maintained. Super happy to see this.
> In the course of using this feature in the `jextract` project, we did learn quite a few things we didn’t already know, and this was conclusive enough that it has motivated us to adjust our approach in this feature. Specifically, the role of processors is “outsized” to the value they offer, and, after further exploration, we now believe it is possible to achieve the goals of the feature without an explicit “processor” abstraction at all! This is a very positive development.
My Summary:
- nothing to do with the choice of backslash vs dollar. Doubles down on dollar being bad (due to backward and cross compat with other languages)
- original choice to use "Template Processors" misguided, reverses course to StringTemplate Literals
- this requires a new paradigm where APIs now need to explicitly support StringTemplates, instead of relying on the Processor to convert them into Strings as necessary (big
leap in my logic here)
- StringTemplates are explicitly still not Strings. This is in line with their "Security Focus First"
- sensitive APIs that depend on StringTemplates should explicitly treat their interpolated results carefully through overloads in a sensitive context.
Obviously I don't know much about the `jextract` project but I can guess 1 possible way this breaks the security concept is if you use the wrong Processor to pass into a Db.query method, for example.
db.query(STR."select * from users where id = \{id};");
This way, you can still do it, but its just much harder to do. Or as an API developer you could deprecate your String overload and insist only on StringTemplate usage from now on.
db.query("select * from users where id = \{id};"); // this is compiled as a StringTemplate
db.query("select * from users where id = \"" + id "\""); // this is still a String, and it's still bad, but can be mitigated by deprecating Stringm method
Disclaimer: i haven't done java in nearly 10 years... i just love theorycrafting. So take my contribution with a pinch of salt please :)
That's actually a really clever mechanism. Although it'll make the common case (basic string interpolation, no need for security concerns) more complicated unless a lot of APIs support a StringTemplate overload.
It's not just you. My reading is that the flaw was toxic Java users made the developers feel so bad about the feature that they canceled it out of spite. I'm almost certain that's not what it was but that's the only information in there.
reply