Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a generic "opener" #564

Open
dr0i opened this issue Oct 10, 2024 · 1 comment
Open

Provide a generic "opener" #564

dr0i opened this issue Oct 10, 2024 · 1 comment
Assignees

Comments

@dr0i
Copy link
Member

dr0i commented Oct 10, 2024

Came up in the MF-Workshop at TH Köln 2024-10-08, inspired by C. Marutschke's idea to let an LLM train using flux and fix:

Provide an "opener" that scans an input (let's say, read up to first 30 kB) and probe that with the various openers and handlers (combined with well known parameters (like recordtagname="lido")). Compare the output, if any other than Exceptions. Pass the one with the most output (or/and most deeply nested/complex structure) as a convenient wrapper.

Could be very convenient for newbies.
I think this is not too complicated and wouldn't suck much ressources.

@dr0i dr0i added this to Metafacture Oct 10, 2024
@dr0i dr0i moved this to Backlog in Metafacture Oct 10, 2024
@dr0i dr0i self-assigned this Oct 10, 2024
@blackwinter
Copy link
Member

blackwinter commented Oct 17, 2024

Hm, involves a little too much "magic" for my taste, I'm afraid... Not to mention that I would contest the assessment that it might not be "too complicated" (for starters, some data are just invalid when arbitrarily truncated).

We could, however, establish conventions for file extensions and MIME types to associate certain input files/URLs with their appropriate readers/handlers (similar to what xdg-open does; see also #96).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

2 participants