与节点一起使用NPAPI插件

Question

I am making a node app which utilizes a npapi plugin. basically I am trying to make it so if the device or browser that connects to the server does not support the plugin it will fall back to the server. currently I have a work around like that works however it requires opening a new window on the host computer whenever a request is sent

(workaround route)

var open = require('open');
var jobs = [];
router.get('/nsjob', function(req, res, next){
    var job = {
            id:(jobs.length > 0) ? jobs[jobs.length - 1].index + 1:0,
            xml://xml,
            params://params,
            callback:function(err, data){
                if(err)
                  return next(err);
                res.send(data);
            }
        };
    open('http://localhost:3000/handleJob/' + job.index);
});
router.get('/handleJob/:id', function(req, res){
    var job;
    for(var i in jobs){
        if(jobs[i].index === req.params.id){
            job = jobs[i];
            break;
        }
    }
    res.render('hjob', job')
});
router.post('/completedJob/:id', function(req, res){
    var job;
    for(var i in jobs){
        if(jobs[i].index === req.params.id){
            job = jobs[i];
            break;
        }
    }
    if(req.body)
       job.callback(req.body.err, req.body.data);
    else
       job.callback(null, null);
    res.end();
});

this works all well and good but seems like a very bad way to go about it however I need this fallback option but it makes it almost impossible to use the host computer while mobile devices are running on the server. if I could load NPAPI plugins to node I could modify the api to not use dom and essentially avoid opening a window on the host computer. however I cannot find a way to do this in node NOT NODE-WEBKIT (until it can be shipped to mobile it is pretty much useless in this case as this is primarily used by mobile users.

Answer 1

You could hypothetically write a Node module which would load an NPAPI plugin, but it would be very difficult. There is definitely not any turnkey solution for this.

FireBreath 2.0 will support a new protocol that could probably be used to do this, but it's still in early planning stages. I don't expect any releases for at least a month or two.