Would RM staff need to validate them? In the working model, a submitted plugin is reviewed by the application developer “prior to publication to ensure that it does not contain any harmful code and conforms to basic style guidance” as it has already been exposed to peer review and testing by other plugin developers in the plugins forum. That does not sound to me to be very onerous for the one application developer who has admitted some 130 plugin submissions to the plugin store.
Keep in mind that the said competitor actually exposes an API for extension writers to code against. I would assume that RM would have to make some effort to do the same and it does so in part do to how it stores data.
As RM now stands, anyone with the skill can generate a program that allows users to perform some action and then generates and runs a SQL script to do that. All of this can be done without RM intervention at all. Problem is, it also gives people a chance to screw their databases up royally. For those who are underwhelmed by some of the RM design changes, I would be rather surprised if a useful API ever happened so that one could interact on any deeper level with RM.
That no API is needed for a SQLite script to operate on the database makes it easier for the RM developers to incorporate user contributed ‘plugins’, if that’s even the right term to use in this case. What might suffice would be an incorporated SQLite manager operating through the RM database connection(s) and using the proprietary RMNOCASE collation. If it supported some forms controls as in Lua scripting that would be a big plus for user friendliness.
As for a plugin shop, it would be great if the app incorporated a plugin manager that could access, download, check for updates, do sideloads of unpublished ones. Taking a page from the model, each script would have a standard header format that could be read to populate the catalog database thus minimising website building and maintenance effort.
In retrospect, it would have been good if we founders of SQLiteToolsFor RootMagic had had the vision and skillset to have designed the website accordingly.
Part of the point that I was going for is that there really is absolutely no need for plugins in anyway, shape or form. Thus as it stands, RM doesn’t need to have any involvement in this. RM uses an openly access database format, so unless they tried to encrypt it, like a certain other competitor, then you, or I, or anyone with programing experience could provide tools to directly alter (update, edit, search) the database. To do this, you really don’t need access to the inner workings of RM.
Even if one wanted to do crazy stuff like generating special reports or something, they can openly pull the data from the various RM files and write their own code to generate the report.
The previously mentioned competitor uses a customized GED file for data storage as opposed to something that can fake it as a relational database, so said competition needs some extra bits to allow people to write their own plugins.
The only issue with this is the proprietary RMNOCASE stuff. I don’t know how the unifuzz workaround would impact the database if one decided to add or change data then try to use the database in RM again.
Well, not quite. There is the matter of the database connections and conflict between the RM app and an external SQLite tool. Neither side knows what the other is doing to the database. The two database engines can read simultaneously but only one is allowed to write. If the other attempts a write, it is blocked and an error must be handled. Moreover, the RM backup operation cannot proceed and freezes if the database is connected to an external app.
Those issues along with Integrity errors that arise from the RMNOCASE mismatch are what argues for an integrated SQLite manager working within the application through the common SQLite engine. That would allow but one connection (or one at a time) to the database from the app and its scripting tool.
I agree with everything else.
Just imagine the support nightmare caused by people who have virtually no db experience getting their meathooks into the RM database, hosing it and then calling for support because of a new “bug” their messing around caused.
We’ve only been doing it for 14 years since RM4 was released. I’ve not seen any surge in complaints of that sort. The user community for the other app that does allow user plugins, both from the store and roll-your-own, seems to resolve issues and provide needed assistance with plugin usage and development.
I think it is reasonable to expect that some users will not dare use a plugin, some will heeding the warning from those plugins that modify data and the users that ignore it will regret not having done so, some will write their own code, and a few will succeed in having theirs peer-reviewed-tested and accepted into the plugin library for others to safely use.
So what that all boils down to is not plugins but adding in some type of tool to allow users to run SQL queries. I am not expecting that will happen anytime soon, just based on all of the wishlist requests that still haven’t seen the light of day after languishing many years.
You also keep mentioning peer-reviewed plugins from the competitor. You do realize that a peer reviewing has nothing to do with anything? One certain user writes a plugin because someone asked for some functionality and that plugin is posted in a forum. The user that wanted the functionality maybe be the only person to ever run it. That user may or may not give any feedback other than "yeah, it works’. No exactly a rigorous review process.
We can dance with terminology but, yes, an integrated SQLite manager. And, sooner or later is mere speculation.
As to peer review, there are established, reliable authors and new authors which likely makes a difference. And, a “Yes, it works” may be all that’s needed for a read-only query.
One big difference between the competing product and RM, I believe, is the level of the users product and general genealogical knowledge. After spending a great deal of time on this and the competitor’s forum I can make the following observations, maybe warranted, maybe not.
- Most RM users seem not to have a lot of exposure to other products, while most of FH’s users have migrated from other products and many from RM.
- The majority of questions on the competitor’s forum are about different ways to use the product and extend its functionality, while most of the messages on this forum seem to be reporting bugs in the software.
- This forum contains a lot of feature requests, while the competitor’s seems relatively quiet on these. Maybe because a lot of feature requests are resolved by user-written plugins.
- The technical expertise, both general genealogical and program-specific, seems to be higher with the competitor’s product.
- Both forums have a handful of super-users who try to help out whenever they can (and actually, some of the former RM super-users who have disappeared from this forum are now on the competitor’s.) But a lot of the super-user messages on this forum seem to be a lot of educated guesses about how things work based on their experimenting.
Based on this, maybe an API into the RM database would be a risky proposition for customer support and the validity of the users’ dbs.
When all is said and done, I commend Tom and Jerry (OK, that’s the first time I’ve typed those two names together and realized they are also cartoon characters, no offense, guys) for the years they’ve spent developing SQL procedures and experimenting with RM, in all its versions, and attempting to make the software understandable and more useable.
Rich
2 Likes
It would appear that a safe compromise might be the offering of a “read-only” API, with a RMNOCASE shim in place, for user contributed plugins.
Safe but falls short of a solution for the OP, let alone a host of other things that may be needed individually by only a few people, in some cases, or a few things that may have popular demand. Read-write scripts that elicit the latter could grease development wheels to incorporate a derivative in the main program.
The idea is to get past no offering.
1 Like
I’m with you on that front. Shall we draft a proposal? Maybe propose a 2-stage implementation:
Stage 1: read-only. Could be as simple as blocking the execution of any script containing UPDATE.
Stage 2: lift that constraint.
1 Like
Stage 1: gather evidence that added functionality might require (little to) no added tech support. Introduce to, familiarize with, and overall bolster SQL concepts and capabilities for users.
Stage 2: expand on potential for user-driven capabilities that might obviate the need for Bruce & Co to wrestle with feature(s) incorporation and support, etc…
Yep, but wanna place a bet on latter being the case? "yes, it works, is hardly peer review. I spent way too much time in academia where peer review is a constant if one is trying to publish.
So what do you think? You wanna write some toy in -insert chosen programming langauge here- that would essentially be a standalone program that allow users to query/update/modify/ their database? Something along the lines of, what was it called? RMTrix or whatever used to be in your forum?
I had actually thought about amusing myself with something that would fill in the missing bits that people want in a relationship list, such as halfs and steps. Just haven’t been bored enough to start it, but that my be an option that someone (whoever codes this third party toy) could add to it.
If one is to write a ‘plugin’ maybe the first thing said plugin should do is make a backup. I am normally not a fan of protecting the clueless from themselves, but this might be an exception.