Split completely from lardawge/rfm?

[emptyflask]

The project has significantly diverged from the original lardawge/rfm repo, so should it still be considered a fork in github? Splitting it would allow repository searches, but on the other hand it would make the project slightly less visible. Thoughts?

[ginjo]

I've been mulling this over, and I can't seem to land on either side. If the fork is helping people find ginjo-rfm from lardawge/rfm, or from sixfriedrice/rfm, then I think that is a good thing. But if there is missing functionality due to the forking, then that's not so good. I'm not familiar with the repo search issue, can you explain that a little bit?

A couple of things to consider.

• Do the original authors - @sixfriedrice, @lardawge, and the others - have any opinions on this? (noting that lardawge/rfm is a standalone repo - has that been a good thing or not?)
• Are there other gems/forks/repos that have been in a similar situation, what did they do, was there any fallout either way?

[emptyflask]

The search feature I was referring to is just being able to search for code within the project at https://github.com/ginjo/rfm. GitHub doesn't index forked projects. Obviously it's trivial to search after cloning the repo locally, but sometimes it's convenient to do it in the browser.

I don't know if there are any other features that forks are missing...

[lardawge]

I am not a fan of forked repos that are actually different gems out in the world. In the early days of github and rubygems that was a thing but now there is much more discipline and effort to find new maintainers for current projects.

It was always my intent, if I actually had projects that continued to use filemaker, to write a new library from the things I have learned. It just never happened.

I would never choose to work on a filemaker project again. It is not a DB solution that should ever be used on the web IMO. It is also super easy to build admin interfaces for internal use using Ember or other front end framework connected to an api.

I would suggest either starting with a new fresh repo and gem or keep it forked. I think it makes it easier to see where it came from as well as original intent and how it got where it is.

My 2cents. Good job with keeping it maintained.

[lardawge]

To add, I will not continue maintaining lardawge-rfm so I can add a pointer to this repo in the readme.

[ginjo]

@emptyflask, I see now what you're referring to. I could swear I was able to search a forked-repo a few weeks ago, but I must have been doing something wrong. That's definitely a drawback.

@lardawge, thanks for the input and the repo pointer. I'm tempted to discuss your thoughts about filemaker and the web... Gitter, google-groups, anyone?

So, still up in the air about the de-forking issue. I've been considering the future of ginjo-rfm, so I'll add this issue into that mix. Just off the top of my head, here are a few thoughts.

• The last few patch-revisions probably should have been minor-revisions to v3.1 I'd like to clean up the features I hastily introduced in those revisions, and release them as v3.1
• I'm starting to feel the weight of complexity (and feature bloat?) in ginjo-rfm, and I'm not sure what to do about that.
• In my recent work on building a filemaker adapter for the rom-rb project, I've realized there are two core functionalities of rfm that really matter: the query builder and the xml parser. Everything else from configuration, to data modeling, to http connections, aren't really rfm's concern.
• Some functionality of ginjo-rfm could be extracted into separate gems. The xml parser is at the top of that list and could be useful elsewhere in the ruby community.
• I can envision a future version of rfm that might only be an adapter to the rom-rb project, or might be a thin gem that merely enhances the rom-fmp adapter with further filemaker-specific functionality.

Now, if I could just find someone willing to pay me for full-time open source development

[emptyflask]

I agree, Filemaker shouldn't be used for web apps, but I write background workers and ruby scripts that sync with it, so rfm is still useful!

rom-rfm is intriguing, I'll have to try it out sometime. Maybe I'll even have some time to contribute.

[lardawge]

@ginjo, I have added a pointer to the readme from lardawge/rfm. Officially killing that project.

@emptyflask, I have no judgment as to what other people use filemaker for. I have worked with it for several years and find it clumsy and outdated for the use cases I am trying to solve. It is much more effective to build admin facing interfaces that can be accessed anywhere without specific software other than a web browser. I am sure there are other reasons it would be useful.

[dmichael]

While FileMaker is far from my favorite storage engine, we do currently have a client using it to run their business and we are using this library to provide a bridge into more modern technologies - with the intent of migrating off of FileMaker. Without this library, our job would have been exceedingly time-consuming.