--- !ditz.rubyforge.org,2008-03-06/issue title: user callback for creating a new global context (more flexible than user initjs) desc: |- User InitJS code is not sufficient for many tasks. For instance, to register additional native functions one needs Duktape/C code. Also, to implement proper sandboxing needs more control than what is possible with perhaps a few kilobytes of Ecmascript code. Perhaps allow a user to set a thread init callback? It could be set into the heap stash, which is then shared for all threads in the heap. type: :task component: duk release: v0.11 reporter: Sami Vaarala status: :closed disposition: :wontfix creation_time: 2014-05-04 14:20:35.277977 Z references: [] id: ca25c7cd62c2059a06ee9e9d3da06a5f6b75f418 log_events: - - 2014-05-04 14:20:36.277881 Z - Sami Vaarala - created - "" - - 2014-05-04 20:07:20.649497 Z - Sami Vaarala - commented - |- Worked on something like this on the heap-thread-init branch. This might not be very useful: since new global environments are created by the user from C code, the user can simply eval some code after creating a new context with fresh globals. The only reason to be able to use a heap-level globInit() callback would be so that some existing code didn't need to be changed. Rather, one would just register the callback and it would automatically get called without co-operation of the existing code. This is not a very big use case. The same argument applies to user initjs code. The use case for that is more along the lines of adding some compatibility wrappers and such (like console.log or perhaps replacements for features removed from Duktape in a newer version), so it might still be worth keeping. - - 2014-05-15 20:49:42.701037 Z - Sami Vaarala - closed with disposition wontfix - |- Rejected because does not really provide anything useful after all. Archived into archive/rejected-globinit.