Re: too small; an 8x10, one of the smaller standard print formats for portraits, is about an 8x enlargement from a 35mm frame. With modern materials and good technique, 8x-11x is feasible, but starting to push it at the edges; I have printed 13x17s off 35mm but I would not want to push it much larger. 35mm does 4x6s, 5x7s and 8x10s perfectly reasonably, which is what it spent most of its time doing for common consumer work. It's worth noting that one of the other common consumer cameras of the 1940s was the Brownie, which output 6cmx9cm images and was routinely contact printed, producing something smaller even than a 4x6.

120 produces images that are between 1.8x (in the 645 format) or 2.5x (in most others) as large, physically, meaning that the common enlargements are only 4x-5x. If you push it, with quality equipment, you start getting into print sizes that are super clumsy to handle like 20x24. I've never printed, personally, anything larger than a 16x20. If you do your own wet processing they're also nicer to work with—35mm negatives are real small and kinda fiddly. 4x5 sheets are also delightful to work with, of course, but they require fighting the camera in the field.

The interesting part comes up when you want to match an infinite set of strings with an algorithm. Probably the simplest such algorithm would be "regardless of input, accept" which isn't exactly useful but would suffice.

It's dissatisfying to have an algorithm that puts weird, arbitrary restrictions on composing languages; for example it's usually the case that if you take a language L1 and a language L2 that are both acceptable to the algorithm, the concatenation (for every string in L1 and every string in L2, the concatenation of their strings is in the new language) language is usually acceptable to the algorithm.

Some commonly used languages do not have all of these properties; in particular the intersection of two context-free languages may not be a CFL, nor the complement. Deterministic context free languages are even more restrictive. You seem to need to give some things up as you move up the language hierarchy in power; in particular string homomorphism and intersection seem to be mutually exclusive in languages more powerful than regular expressions.

If you're interested, the theory of abstract families of languages has been studied, although I do not know a lot about it myself.

The other way of doing it is things like CRDTs (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...) which have a join operation for any two data values.

You have to keep it in the back of your mind that it's a thing, but working without consistency can be done.

* Node as a runtime is deeply mediocre, in my experience. You can usually solve this by throwing more (usually virtualized) hardware at the problem.

* Meteor's architecture is (at present) tied into MongoDB's oplog tailing. You can scale it up through sharding, through alternate libraries, and DDP itself is not tied to MongoDB at all. IIRC fixing this was a goal for Meteor 2.0.

Both of these can be worked around. If nothing else, the Meteor web side will talk to anything doing DDP, and DDP is not that hard to deal with.

Suffice to say if you try to use your ordinary everyday life intuitions doing higher dimensional mathematics you will continuously embarrass yourself until you learn not to. Some folks develop the necessary adjustments and have higher dimensional intuitions; I do not and have to do the math anywhere higher than around 4.