Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate binary arch from non-arch specific content #11

Open
markc opened this issue Dec 27, 2011 · 1 comment
Open

Separate binary arch from non-arch specific content #11

markc opened this issue Dec 27, 2011 · 1 comment

Comments

@markc
Copy link
Contributor

markc commented Dec 27, 2011

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.

@mschwartz
Copy link
Owner

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:
#11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants