turning mjsingle and mjpage into a single library about mathjax-node

[anandthakker]

@pkra I'd wondered the same, and thought I was missing something too :). Might be easier to do this after #37, but maybe not. (I'm still planning to work up a PR for that, but still a little busy this week.)

[dpvc]

The main configuration options for the two libraries are completely different, and so you would end up with a library that has two basically separate sets of configuration paths and two internal processing paths. I don't see the win to that. It seems to me that this unnecessarily complicates the internals of the library for the small gain of sharing the initialization functions. If we really want to share those, it might be better to pull them into a common file loaded by both libraries.

I think we are still learning what the use-cases for MathJax-node are going to be, and I suspect that a redesign of the mj-page interface in particular may be something that we should think about when we have a better idea of the uses that it is going to put to. So I would not want to move too quickly to combine the two separate interfaces.

[pkra]

Thanks, Davide. I didn't expect bigger problems but it turns out I'm wrong.

My thinking was that mj-page handles HTML fragments and mj-single is just for particularly small fragments. I can see that this isn't the case and I'm wondering if such an approach is feasible.

But let's shelf it for the time being.

[dpvc]

I'm wondering if such an approach is feasible.

I'm sure it is possible. The question is what are the trade-offs in doing it. A single file is always nice, but if it is more complicated, perhaps that out ways the benefit.

let's shelf it for the time being.

Sounds good. I think things are still settling in with MathJax-node. It might mean that we don't get to merge all pull requests, however, until we settle on a more clear sense of what the API needs to include, depending on the contents of the pull request.

[pkra]

Closed in favor of #206