Open scripting opened 11 months ago
Maybe the Electron version could be client-only, making API calls to a Feedland server running someplace else.
@scotthansonde -- Thanks for the comment. ;-)
I think you have a FeedLand installation running that way.
Would it benefit you some way to have an Electron UI for it? Is that something you'd want?
Also, what are the costs?
@scripting Yes, I do have a server. The Node server costs $5 per month at the Digital Ocean competitor vultr*, the database runs for free at PlanetScale. I can certainly document how to duplicate my setup.
As for an Electron app as a frontend for my server, I can't think of how it would benefit me. Right now I wouldn't want it.
*I had a $250 coupon, so I'm getting 50 months for free! That's the only reason I picked vultr. 😛
Skimming through the database.js code, it seems that you're using standard SQL syntax for your database calls which would run fine on SQLite. It's possible that the code, except perhaps for the db initialization, would run fine as-is on both platforms.
@yudel -- that's great to know! If anyone is inclined to test that, please do and let me know.
Does feedlandInstall process work for an SQLite database?
@scotthansonde -- I didn't imagine there was much advantage, unlike with Drummer, where having the files stored in my local filesystem matters a lot in terms of the kinds of systems i can make.
I'm not even sure how much value there is in running it completely self-contained, but I had the thought that we could all cooperate on scanning feeds, so we could get more instant updates for more feeds by sharing info.
I think of things like that but very rarely actually do them. ;-)
I was able to run the create table commands in https://github.com/scripting/feedlandInstall/blob/main/docs/setup.sql without errors.
However, ChatGPT provides some caution here on what would be involved in working with the two databases: https://chat.openai.com/share/c07b92d7-f909-4eae-86d3-e33e6f641fe7
It's might be more work than you want to take on at the moment, but I imagine that you could create an abstraction layer that makes the specific database being used transparent to the code that depends on it, kind of like the driver concept we had in Frontier, or abstracting away differences between XML-RPC and SOAP via SCNS (also in Frontier). From @yudel's conversation with ChatGPT about migrating from MySQL to SQLite, the differences between the two for this usage seem to be small, so the abstraction could be quite thin, in theory. The installation steps are probably where the heaviest lift would be needed.
SQLite is a very popular choice for local relational database, is well supported on many platforms, performs well, and has a very permissive license. (I've got an amusing story about that from my time at Microsoft actually.)
@jsavin -- hey Jake -- nice to hear from you! ;-)
I've learned a lot from this thread, specifically that I should try to do a project with SQLite, but probably not this one.
I'm starting to scope out if it would be possible to create an Electron version of FeedLand.
I had a conversation with ChatGPT about that. We did not arrive at a plan.
We use MySQL, I can't convert to another SQL, we have to use the same codebase in all versions.
If, after reading the chat, you have ideas, please post a note here.
BTW, here's the feedlandInstall repo. It has full instructions for setting up your own FeedLand instance.