Now this would be cool. I too have my large music collection saved as MP3 files, where I created its own custom FileType ‘database:MusicDB’ and its default template. I have written queries to locate and display my results in the terminal–the queries work very fast (with indexes).
If ‘query’ command could incorporate database capabilities (e.g. WHERE clause structures) or new CLI commands similar to the Cypher language (i.e. MATCH) that could better leverage the BFS attribute paradigm. TrackerBase showed us the basic and extended capabilities of BFS. If Haiku had a simple query language that is specifically developed to ‘query’ the BFS data/attribute structures, it would replace complex query bash scripts to simplified query scripts.
The queries should also be able to display the results in various ways. I could define a query that groups songs by album, by artist, by record, by genre etc.
Let say I do a query grouping by artist, then the results would look like this:
Alanis Morissette/Track 1
Alanis Morissette/Track 2
Alanis Morissette/…
Beastie Boys/Track 1
Beastie Boys/Track 2
Beastie Boys/…
…
Same search but grouping by artist and album:
Alanis Morissette/Album 1/Track 1
Alanis Morissette/Album 1/Track 2
Alanis Morissette/Album 1/…
Beastie Boys/Album 1/Track 1
Beastie Boys/Album 1/Track 2
Beastie Boys/Album 1/…
…
Group by genre, artist and album:
Pop and Rock/Alanis Morissette/Album 1/Track 1
Pop and Rock/Alanis Morissette/Album 1/Track 2
Pop and Rock/Alanis Morissette/Album 1/…
Hip-Hop/Beastie Boys/Album 1/Track 1
Hip-Hop/Beastie Boys/Album 1/Track 2
Hip-Hop/Beastie Boys/Album 1/…
Queries needs to be visual, discoverable and self learning. That means when you start to use the query functionality you get visual feedback and help.
I see this as an extension to the current type-ahead filtering.
I have a really vague memory that someone wrote a command line tool to use SQL queries for BFS attributes a LONG time ago, around the time of Be Inc’s demise and the beginning of Haiku. Not sure if it supported WHERE clauses. And I have no idea where to find that or what was the name of the tool.
If it was a SQLite3 wrapper for Haiku, that would allow a lot of software to use BeFS that otherwise wouldn’t. One example is that Draken visual language editor I was hoping to adapt to Haiku which uses SQLite as its only file format internally.
Speaking of which, the Lua 5.2 backend I thought of adapting works already and several Lua versions are in HaikuPorts. I’d prefer to use the C++ backend for the editor itself but it currently uses Qt. Also, Luau wouldn’t be a hard port but I need to get familiar with Drakon first and foremost. Maybe I’ll just use the generators and rewrite the editor.
After reviewing the documented schema of the file format of Drakon, I’ve discovered it’s geared toward the storage of the diagram format more than that of a code format. Fortunately, the generator can be written to export to any code-centric file format including another graphical language.
I’ll be ending the thought experiment of a graphical scripting engine in this thread now. It appears that it was partially a bust. My research now proceeds unto binary schemas for SQLite and version control operating on a common webserver.
This is a modern take on a shell: Nushell. (cross platform - in rust) Its partly graphical, and has lots of contributors.
Nu draws inspiration from projects like PowerShell, functional programming languages, and modern CLI tools. Rather than thinking of files and data as raw streams of text, Nu looks at each input as something with structure. For example, when you list the contents of a directory what you get back is a table of rows, where each row represents an item in that directory. These values can be piped through a series of steps, in a series of commands called a ‘pipeline’.
But why would you want that? These applications can store their data in an sqlite database just fine. Why would you make them use thousands of empty files with attributes instead, resulting in slower performance and waste of disk space?
It’s been said that Haiku provides a cohesive experience compared to the likes of Linux which is piecemeal. If I need a mimetype for a SQLite3 based file format, how do I identify it?
I’m thinking in that direction because it could easily be upgraded to allow collaboration online by putting the file manipulation onto a SQL based server, as was done for Drakon.
Collaboration tools coupled with replica sets of servers and in case of heavy loads, sharding of database repos, make for a better user experience if done right. It might even bypass the need for local version control tools. Thinking ahead, that doesn’t sound so great.
Maybe the best solution toward a cohesive scripting experience is to give the common tasks a graphical user interface. That way the staring at a blinking cursor as you try to remeber the name of a cryptic command syndrome will be remedied.
I was hoping to make a graphical programming and scripting engine but the one problem staring me in the face about it is that version control and file differencing is difficult in graphical languages.
Yes, but that does not mean “blindly use attributes for everything”. And especially attempting to fit an existing app that was designed and tested with sqlite to work with another quite different engine and storage seems like a bad idea.
If you are designing an application for Haiku, you can think about what is useful to expose to other apps as attributes, what is convenient to store there rather than in the file body, etc. But, you can’t take an app that was designed with a completely different model in mind, force it to store its data as attributes, and call it a day.
OK. What if I exported a file type and file type version as attributes in a file based on SQLite? Would the Haiku Filetypes utility be able to track it then?
Don’t know what the conversation drifted to, but replying to the original message: Would it be easier to just… use PowerShell and then load Haiku API .dlls and then interact with those objects?
I wanted to chime in here and say that if this shell idea does become a thing, definitely take a look at Nushell. It really takes linux shells and makes them more modern. It’s pretty cool actually, and much better functionality and syntax-wise than Powershell, imho. Although, maybe leave Nushell’s pure-functional leaning paradigm aside, lol.
I think the derivation came about when we realized that the shell is the GUI, and that you only need to create a graphical application for what the shell does. Anyway, if we can make a new terminal with access to the API.
I was biting my tongue and wondering is anyone else would mention that. Now that the APi is at least partially mapped, you should be able to load any .Net assemblies and use them in PowerShell directly.