To be compatible with the parsing/loading functions in
@loaders.gl/core such as
load, a parser needs to be described by a "loader object" conforming to the following specification.
|Required||Short name of the loader ('OBJ', 'PLY' etc)|
|Required||Three letter (typically) extension used by files of this format|
|Required||Array of file extension strings supported by this loader|
|Optional||Indicates the type/shape of data|
|Every non-worker loader should expose a |
Note: Only one of
extensions is required. If both are supplied,
extensions will be used.
|Guesses if a text format file is of this format by examining the first characters in the file|
Each (non-worker) loader should define a
parse function. Additional parsing functions can be exposed depending on the loaders capabilities, to optimize for text parsing, synchronous parsing, streaming parsing, etc:
|Parser function field||Type||Default||Description|
|Asynchronously parses binary data (e.g. file contents) asynchronously (|
|Parses binary data chunks (|
|Synchronously parses binary data chunks (|
|Atomically and synchronously parses binary data (e.g. file contents) (|
|Atomically and synchronously parses a text file (|
|Asynchronously reads a binary file and parses its contents.|
Synchronous parsers are more flexible as they can support synchronous parsing which can simplify application logic and debugging, and iterator-based parsers are more flexible as they can support batched loading of large data sets in addition to atomic loading.
You are encouraged to provide the most capable parser function you can (e.g.
parseToIterator if possible). Unless you are writing a completely new loader from scratch, the appropriate choice often depends on the capabilities of an existing external "loader" that you are working with.