Quote - I'm asking because in skimming the Cornucopia thread it appears that the script in question creates a "sequence of meshes" which is what the Barton export script does though it is limited to the .obj format rather than the list of Vue compatible formats in the thread.

The Vue version is limited to the OBJ or RealFlow BIN because the Python module necessary to support reading the compressed Blender data is broken due to a bad native DLL.

Quote - Does your import script eliminate the requirement for having an export script by handling both ends of the pipeline in effect?

The Poser version can read the Blender files directly.
These are similar to the RealFlow BIN files in that the data is binary rather than text like OBJ and they are gzip compressed.
Simulation setup in Blender is done by hand, then either Blender or (the command line version) elbeem is used to generate the simulation data.
It would obviously be desirable to automate this process, and while not impossible, the need to tweak meshes in Blender (i.e. an inherently manual step) as part of the sim setup makes doing so probably not worth the effort.

Quote - I'm definitely interested in an alternative method that is more resource friendly for prepping the simulation so it is readable by Poser.

As I said above, the key is to redefine the geometry of a single object so that only one frames worth is loaded at a time.
This is possible because both Poser and Vue provide frame setup callbacks that can be used to do this.

Quote - The main (only) advantage that I've found for converting to .obj is that the results are usable in any program that handles .obj sequences.

Obviously you have to use what the target program can read.

Quote - Now my other question is: How does your import script handle extracting the information from within the Blender file.?

The Python way to handle binary data is to use struct.unpack with the appropriate template strings.

Quote - As you noted in the discussion in the Cornucopia thread .obj format while simple to parse is much larger in size than a binary format. in the interest of resource efficiency being able to use binary formats is much more appealing.

With the standard library modules, Python is capable of reading any simple format (OBJ, Realflow BIN, Blender BOBJ), with extra modules it would more than likely be possible to support other formats (there are a couple or so Python based suites/libraries that could supply the required routines) if useful but this seems unlikely to be necessary as directly reading the native output of the fluid sims is possible.