Hi Martin, Aren't there plenty of successful os projects with GPL? Is there any reason why it doesn't work in the node community, besides what everyone else is doing? Are there a majority of commercial project using node?
Please don't mistake the questions for anything combative, just trying to get a full grasp before switching. Thanks, Saleem On Friday, October 5, 2012 8:39:50 PM UTC-4, Martin Cooper wrote: > > GPLv3? Really? > > That seems like an odd choice in Node's predominantly MIT / BSD world, > especially if you're looking for adoption. > > -- > Martin Cooper > > > On Fri, Oct 5, 2012 at 10:24 AM, Saleem Abdul Hamid > <mee...@gmail.com<javascript:>> > wrote: > > More updates :) > > > > I added a plugin api, and wrote two example plugins. Now you can use > those > > plugins to include coffee-script and jade files. So you can include jade > > template views in your bundles and then render the pre-compiled function > > client-side as much as you want. There's a demonstration screencast of > both > > plugins in the readme. > > > > I also forgot to mention that I added a lot of caching to the server and > > cleaned up some performance bottlenecks in the proof-of-concept version, > so > > it now serves files faster than connect (even without taking into > account > > the optimizability advantages). The crude, but sufficient ;), benchmarks > are > > available in the readme. > > > > https://github.com/meelash/Mundlejs > > > > > > On Saturday, March 24, 2012 5:04:52 PM UTC-7, Saleem Abdul Hamid wrote: > >> > >> tl;dr - Client-side require with a server-side component that caches > >> dependencies, bundles them, and caches the bundles. Need feedback on > >> the concept, syntax. Need suggestions/contributions on implementation. > >> Although, this works for me, it is almost just a proof-of-concept, > >> needs work. > >> > >> > >> As part of a project I'm working on, I spent a few hours writing a > >> little client-side module loader with a server-side component enabling > >> what I think is a pretty neat meaning to CommonJS module syntax. This > >> morning I pulled it out of the rest of my project and attempted to > >> package it in a useful way for others to use. > >> > >> The basic idea is this- in your client-side code, you can use require > >> in either a "synchronous" or asynchronous fashion- > >> module1 = require('some/path.js'); > >> require('some/other/path.js', function(err,result){module2 = > >> result;}); > >> > >> An asynchronous require makes a call to the server component to get > >> the file in question, but before returning the file, the server parses > >> it, finds all the synchronous require calls, loads those files as well > >> and returning the whole thing as a package. That way, when the > >> original file that was asynchronously loaded is executed and comes to > >> one of those synchronous require calls, that file is already there, > >> and the require is actually synchronous. > >> > >> At this point, maybe this screencast demo will help to clarify how it > >> works: http://screencast.com/t/nOU53BRYUAX > >> > >> Put another way: > >> If I async require fileA, and fileA has synchronous dependencies on > >> fileB, and fileC, and an asynchronous dependency on fileD, the server- > >> side component will return (in a single "bundle") and keep in memory > >> fileA, fileB, and fileC, not fileD, and it will execute fileA. > >> The client-side also separates fetching the files and eval'ing them > >> (the method of getting files is xhr+eval). So, let's say fileA has > >> require('fileB'); that executes when the file is parsed and executed > >> on the client, but require('fileC') is inside a function somewhere. > >> Then fileA will first be eval'ed, then fileB when it comes across > >> that, and the text of fileC will just be in memory, not eval'ed until > >> that function is called or some other require to it is called by any > >> other part of the program. > >> > >> Another example- > >> fileA has dependencies fileB, fileC, fileD, fileE, fileF > >> fileG has dependencies fileC, fileE, fileH > >> > >> When I call require('fileA', function(err,result){return 'yay';});, > >> the module loader will load fileA, fileB, fileC, fileD, fileE, and > >> fileF all in a single bundle. > >> If I, after that, call require('fileG', function(err,result){return > >> 'yay';});, the module loader will only load fileG and fileH! > >> > >> Hopefully, that's clear.... > >> > >> The advantages- > >> Being aware of the difference in synchronous and asynchronous require > >> in your client-side code make it extremely natural to break all your > >> client-side code into small reusable chunks- there is no penalty and > >> you don't have to "optimize" later by deciding what to package > >> together and what to package separately. > >> Handling dependencies becomes nothing. You don't have to think about > >> it. > >> The server can have a "deployment" mode, where it caches what the > >> dependencies of a file are and doesn't ever need to parse that file > >> again. > >> In "deployment" mode, the server can also cache bundles of multiple > >> files that are requested together, so when another client requests > >> that same bundle, it is already in memory. > >> > >> To sum up: > >> xhr+eval-when-necessary client-side module loader > >> both synchronous-ish and asynchronous require in your client side-code > >> --the synchronous require is actually a command to the server-side > >> component to bundle > >> server-side component > >> --parses for dependencies and bundles them together > >> --can cache dependency parsing results and whole bundles > >> > >> > >> So- thoughts? Is this a horrible idea? Are there some gotchas that I'm > >> missing? > >> > >> Specific advice needed- > >> • How to package this in a way that it can be easily used in other > >> projects? How can I make it integrate seamlessly with existing servers > >> and make it compatible with different transport mechanisms? > >> • How to handle path resolution? > >> • Suggestions for licensing? > >> • Suggestions for a name- (Mundlejs is a portmanteau of Module and > >> Bundle- didn't really think long about it) > >> > >> Things that need to be (properly)implemented: > >> • server-side "parsing" is just a brittle regexp right now: > >> (line.match /require\('(.*)'\)/) > >> • neither type of server-side caching is implemented (pretty easy to > >> do) > >> • uniquely identify clients and keep the server away of what modules > >> they already have, so we can just send the diff of cached modules- > >> currently, I'm sending the entire list of already cached modules with > >> every xhr call, so the server doesn't load a dependency twice. > >> • proper compatibility with module specifications (i.e. CommonJS)- > >> right now, it's just require and module.exports > >> > >> > >> Code is available here: https://github.com/meelash/Mundlejs > >> To test it: > >> from Mundlejs/tests/, run > >> node server.js > >> visit http://127.0.0.1:1337/ and open your browser console. > > > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to nod...@googlegroups.com<javascript:> > > To unsubscribe from this group, send email to > > nodejs+un...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
