[tech] Easier hello world about transit_model HOT 8 CLOSED

The first one named parse_zip_read() takes a std::io::Read as input. And that is actually the reason why we started using the verb parse instead of read, to avoid something like read_zip_read(read: impl Read)

from transit_model.

I think that would be a very nice API ❤️. Note that this is only about the GTFS API, maybe something similar for NTFS and the rest of the public API.

from transit_model.

It's a nice API, yes.
Not sure that from_zip and from_path would be used a lot (except for forcing one) as the perf price to have both is low.

At first sight, I would put it in 'polish' category, so my question for working on it is: what is the expected gain on that?
A lot of people would use the lib to do some opensource PT-stuffs that we would consider reusable?
(I compare it with the yak-shaving part of changing all the error-handling that seems more valuable, but I'm absolutely not confident in my judgement/ideas on that).

from transit_model.

yes I agree the gain would be quite minimal, it can maybe bring some reusers and lower the step to use transit_model (even for CanalTP), but the time to implement this is also very limited so I guess so trade off is not bad.

For from_zip and from_path you're right they are only meant to be used if the default magic to call the right one is not ok for some specific use case.

from transit_model.

After discussion with @woshilapin:

• parse_zip_read(read: impl Read, source_name: &str)
• parse_zip_path(path: impl AsRef<Path>)
• parse_dir_path(path: impl AsRef<Path>)
• parse(path: impl AsRef<Path>)

from transit_model.

no parsing from reader?

from transit_model.

The first one named parse_zip_read() takes a std::io::Read as input. And that is actually the reason why we started using the verb parse instead of read, to avoid something like read_zip_read(read: impl Read)

what is source_name ?

from transit_model.

it's uggly but it's an artifact since the FileHandler needs a name for better errors.

from transit_model.