| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
More or less the same rationale as the previous commit, but for reading. This
makes for nice symmetry with writing, at the cost of a slightly more annoying
reader interface since the source doesn't know its block size or name.
|
|
This makes the paging mechanism an internal detail once again. While it's
conceptually elegant to simply have a single write interface and have the block
dumper just be another implementation of that, unfortunately it is not
practical. The inlining of serd_block_dumper_write() is a significant
performance boost, because it avoids a non-inlinable function call of overhead
per character.
Compared to the SerdByteSink approach, this removes the burden and overhead of
needing to dynamically allocate the structure itself.
|
|
Essentially replaces serd_buffer_sink_finish() with serd_buffer_close(), which
makes writing to a buffer consistent with writing to a file or anything else.
|
|
|
|
Especially with the new functionality, the complexity of the command-line
interface alone was really becoming unmanageable. The serdi implementation
also had the highest cyclomatic complexity of the entire codebase by a huge
margin.
So, take a page from the Unix philosophy and split serdi into several more
finely-honed tools that can be freely composed. Though there is still
unfortunately quite a bit of option overlap between them due to the common
details of reading RDF, I think the resulting tools are a lot easier to
understand, both from a user and a developer perspective.
|
