Hal Gumbert (@campsoftware) has started an interesting topic on Twitter today:
“I would love to include FileMaker plugins IN the FileMaker file within the ‘File Options’ dialog. Should have ‘File Plugins’, ‘App Plugins’, and ‘Computer Plugins’. ‘File Plugins’ would be stored IN db.”
This topic quickly turned to be full of ideas and opinions. Way more than can reasonably fit in Twitter’s message length limit.
Since my company is a FileMaker plug-in vendor and we also did quite a bit to ease installing FileMaker plug-ins with our 24U Plug-In AutoInstaller (available since 2003), I got the idea to do an interview over Skype with Hal. I also invited Mark Cyrulik (@mcyrulik) who participated in the discussion with pertinent comments.
I am glad that Hal and Mark agreed and so I can now share the whole interview with you.
Let me start by introducing the participants.
Hal Gumbert (@campsoftware) is a FileMaker consultant and developer with CampSoftware.com based in Orlando, FL. Hal is certified in FileMaker versions 7, 8, 9, 10, and 11. CampSoftware assist small businesses with their needs and share their tools with other developers like FMSnippets. CampSoftware also offer their own plug-in installing utility called FM Extensions Installer.
Mark Cyrulik (@mcyrulik) is a Systems Analyst and in-house FileMaker and web developer. Mark has over 6 years of FileMaker experience developing custom FileMaker and web solutions for customers and internal users, as well as integrating FileMaker with internal systems and various third party applications from accounting systems to manufacturing software.
OK, now let’s dive into the topic. I didn’t have a Skype call recorder ready so we briefly discussed using text chat and will follow up with voice call later…
HOnza: Hal, Mark, thank you again for joining me for this discussion about the possible future of installing FileMaker plug-ins.
Hal: Thank you! It’s fun thinking about what we would like.
HOnza: Hal, you have mentioned your idea on Twitter. Basically in addition to computer wide and user specific installation locations, you would like to have file-specific installation option added. What is the primairy reason you’re hoping for this?
Hal: Installing extensions has always been difficult for users. Developers find it to be not so hard to install them by hand. Automation has been a bit harder. I love how FileMaker databases can embed image files on layout, so I was thinking how nice it would be to store extensions too. After all, most databases are designed to work with specific extensions.
HOnza: OK, so you’re meaning solution-specific installation rather than file-specific?
Hal: Well, there’s no definition of a ‘solution’ in FileMaker, but we all know what a file is. The idea is to put the extension to be used with that particular file into the File. Maybe via the File Options Window where you set the Startup Script and Startup Layout. A File Extension would be used first, then a Application Extension, then the Computer Extensions. The other problem is that you never know what extensions are installed on a particular computer. Placing them in the database file removes all those worries.
HOnza: That’s really innovative idea. Unlike AutoUpdate, this would require no scripting at all. Mark, you had a different idea. Mentioned server storage. What benefits do you see in that approach?
Mark: All of our solutions/files are built for a specific internal customer of ours. These all end up being different workflows, and for the most part have different functional requirements. We have a basic set of plugins that most of our solutions utilize. Distributing the necessary plugins to all of our external users has always been an obstacle for us. Hal’s idea would certainly solve the problem. It would introduce another. We would have to visit each file and update them when a new version of a plugin was released. If we could reference a FileMaker Server side store of available plugins in our files, we would have one place to update and all of our files would have any new functionality available the next time a user logs in.
Hal: So Mark, maybe there should be both File based Extensions and Server based Extensions. That way you could choose either implementation. I was wondering, does the current AutoUpdate mechanism, not work for you?
Mark: I would like to see both an in-file solution and a server based solution. The current AutoUpdate is hit or miss for us. Since we have a good number of external customers, we frequently have issues with companies who greatly restrict the acces a user has to directories on their computers. This makes saving the plugin a problem. With some of our mac users, even when a plugin is prepared correctly, if users have certain third party un-zip utilities, the plugins are not able to be un-zipped properly – generating errors.
Hal: I have to head out for the fmpug meeting. I’d love to talk about this via an audio chat… [Hal has left]
HOnza: Seems like we could dig really deep here. At least a lot to think about… Mark, leaving aside how difficult it might be for FMI to implmenet this, how would you see possible conflict when having mutliple instances/versions of the same plug-in?
Mark: I think a precedence would have to be established. For instance, if an in-file plugin is found, use that, otherwise look to the server, etc.
HOnza: Some plug-ins use idle-time processing, persistent data storage or shared resources. Can you recall any situation where this would cause you a problem or do you take it as something only the plug-in vendors should care of?
Mark: I can think of a few where it would. I think that should be something left up to plugin vendors. If FileMaker could implement this, they would also have to include the ability for you(as the plugin developer) to not allow these features(in-fle, or server side store) – similar to how you can find plugins that are not FileMaker Server compatible.
HOnza: Seems reasonable and a lot of new questions are popping up. So thank you both again for opening this topic with these inspirational initial thoughts and I hope we’ll be able to elaborate on more details in a voice call soon…
…now continued as a voice conference call recording:
Your browser does not support the audio element.
Please excuse a bit lower quality of the audio. It was my first Skype call recording and I obviously still need to figure out the best settings.