mschwartz
commented
12 years ago I love the suggestions you're making.
But for now, the HTTP server, and especially it's speed, are the real reason to use SilkJS.
I'm thinking about a JSGI http server implementation, then it might make sense to start making separate repositories.
On Dec 26, 2011, at 5:34 PM, Mark Constable wrote:
Just an idea but the silkjs executable itself has to be arch specific (i686, x86_64, OSX etc) but the Javascript and documentation is reusable across all architectures, distros and operating systems (with suitable EOL line feed twiddling) so a separate repo for the Javascript and documentation, a bit like SilkJS-extjs would be worth considering.
I'll be doing this when creating SilkJS pakages for Archlinux, and it would also apply to Debian packages, so it would make it easier for me to manage if the upstream repos were also split, and because it might be a good idea anyway.
Reply to this email directly or view it on GitHub: https://github.com/mschwartz/SilkJS/issues/11
Just an idea but the silkjs executable itself has to be arch specific (i686, x86_64, OSX etc) but the Javascript and documentation is reusable across all architectures, distros and operating systems (with suitable EOL line feed twiddling) so a separate repo for the Javascript and documentation, a bit like SilkJS-extjs would be worth considering.
I'll be doing this when creating SilkJS pakages for Archlinux, and it would also apply to Debian packages, so it would make it easier for me to manage if the upstream repos were also split, and because it might be a good idea anyway.