3 ms·

Hi there - the engine itself is closed source, everything we build on top of it is open-sourced. So if someone built a competing engine that used KL (not sure w

Hi there - the engine itself is closed source, everything we build on top of it is open-sourced. So if someone built a competing engine that used KL (not sure why they would!), then you would be free to take your code wherever you liked. If we move to type inference in the future, then the KL code will be JavaScript. Right now we declare types, but in the future we'd like to just throw a compiler error if we can't infer. That way people will have completely portable code.

azakai 15y ago
> That way people will have completely portable code. Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?
- FabricPaul 15y ago
  It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable working with - so we looked at JS and decided we could create a variant for performance. We don't give pointers, and we do things client-side like guarded arrays (not necessary on the server). Memory management is handled by the core. I will get our guys to put a post up that covers KL in more detail - security was a major consideration for us.
  - azakai 15y ago
    Interesting, thanks. Looking forward to that post.
    - FabricPaul 15y ago
      I linked this elsewhere on the thread, but you might find it interesting in the meantime: http://fabric-engine.com/2011/10/couldnt-you-just-use-javascript-2/ http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... There are more details on KL, and the reasoning why we didn't use JavaScript
      - azakai 15y ago
        Thanks, that was interesting. While I have you here :) , can you please elaborate on your Bullet/Fabric demo? Specifically, how did you get the Bullet C++ code to run on the Fabric Engine? (Since that doesn't use C++?)
        FabricPaul 15y ago
        Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-windows/ http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail. Does that answer your question properly? I can get more info if needed.
        azakai 15y ago
        Thanks, that does answer my question. I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL. I assume integrating existing C++ libraries to Fabric Engine has no security model, then?
        FabricPaul 15y ago
        Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager
        azakai 15y ago

azakai 15y ago

> That way people will have completely portable code. Makes sense about portability, but what is your security model? Are you using static analysis, sandboxing like NaCl, or something else?

FabricPaul 15y ago
It's actually a reason why we went down the 'create your own language for operators' path - we originally wrote our operators in C++, but when we shifted to the browser it was clear that wasn't going to go well :) We looked at sand-boxing, but given how long the NaCl guys took to get it working, we really didn't want to take that on as a start-up. We also wanted something that a web developer would be comfortable working with - so we looked at JS and decided we could create a variant for performance. We don't give pointers, and we do things client-side like guarded arrays (not necessary on the server). Memory management is handled by the core. I will get our guys to put a post up that covers KL in more detail - security was a major consideration for us.
- azakai 15y ago
  Interesting, thanks. Looking forward to that post.
  - FabricPaul 15y ago
    I linked this elsewhere on the thread, but you might find it interesting in the meantime: http://fabric-engine.com/2011/10/couldnt-you-just-use-javascript-2/ http://fabric-engine.com/2011/10/couldnt-you-just-use-javasc... There are more details on KL, and the reasoning why we didn't use JavaScript
    - azakai 15y ago
      Thanks, that was interesting. While I have you here :) , can you please elaborate on your Bullet/Fabric demo? Specifically, how did you get the Bullet C++ code to run on the Fabric Engine? (Since that doesn't use C++?)
      - FabricPaul 15y ago
        Sure - we designed Fabric to be extendable, so it can include existing c++ libraries. So we just integrated the Bullet SDK. http://fabric-engine.com/2011/11/building-extensions-on-windows/ http://fabric-engine.com/2011/11/building-extensions-on-wind... covers the extension model in detail. Does that answer your question properly? I can get more info if needed.
        azakai 15y ago
        Thanks, that does answer my question. I asked because I work on compiling C++ into JavaScript, and I was curious if your technology included something to compile C++ into KL. I assume integrating existing C++ libraries to Fabric Engine has no security model, then?
        FabricPaul 15y ago
        Right - they have to be 'trusted', much like a plugin. People will have to explicitly choose to install them. Right now we bundle them all in he plugin, but that's just until we write the manager
        azakai 15y ago