This technique was however even harder to understand and implement for an average developer, so it did not get adopted very widely. The technique was based on performing a find which, for performance purposes, evaluated an unstored calculation in a field on the server. Since the only way to trigger a PHP script (without switching to Safari) from within the first version of FileMaker Go was through the Web Viewer and it was not easy to process the result of such call, one more technique has been developed by CNS to trigger server-side plug-in features. ![]() Originally, this was primarily wanted to access and manage externally stored files on the server’s storage, but with the release of FileMaker Go this demand significantly grew because developers wanted to be able to use server-side plug-ins to provide missing (mostly computing) features to their mobile solutions. Plug-In On Demandīesides performance optimization, another common reason for triggering server-side scripts on demand has been to intentionally evaluate a plug-in function on server. However, even though being quite successful, these solutions were still too difficult to implement and deploy for an average developer. The most popular ended up being SkeletonKey’s FMRPC and 1-more-thing’s FMSDIFM. But since it is relatively straightforward (if you have at least basic knowledge of PHP) to trigger a script this way and it does not take more than a few seconds (in the worst case of not yet initilized web publishing), and it is also naturally secure if you do it properly, this technique has actually been adopted quite widely, and even led to some companies introducing ready-to-use solutions. Scripts triggered this way are not really running the same way as server-side scripts, as they exist in the context of the web publishing session. This was, however very hard to set up without introducing security risks, and I don’t know of anyone actually using this technique.Īnother way was to trigger scripts through the PHP web publishing. One possible technique to use was to create a one-time server-side script schedule and then somehow remotely trigger the schedule through the fmsadmin command-line tool. There was no obvious way but a few ways actually existed. This was sufficient to replace the robot machine for long labor intensive tasks but could not be utilized to speed up short (under 1 minute) tasks, whose primary reason for slowness was the need to transfer a lot of data between the server and the client. ![]() So to have a task processed by a server-side script you could have had to wait up to a minute. There was no obvious way to run a server-side script on demand, and schedules could not be set up for shorter period than one minute. One of the main drawbacks of server-side scripts has been that they had to be scheduled. FileMaker Server 12 also finally supported multithreading, enabling you to run a labor intensive server-side script without significantly affecting performance of connected clients. But realistically, it was not very easy and safe to use them until the release of FileMaker Server 12, when the server-side scripting engine was completely separated from the database engine to make sure that even a disaster such as plug-in crash does not affect the main database hosting functionality of FileMaker Server. Server-side scripts could also benefit from server-side plug-ins almost from the beginning… Well, officially. One of the few exceptions persisting, probably due to licensing issues, has been the Save as PDF script step, finally made available in FileMaker Server 16. ![]() At that time only a limited subset of script steps were compatible with server-side scripting, but some of the robot machines could finally be replaced by this feature.įollowing versions of FileMaker Server were slowly extending the set of script steps supported by server-side scripts, until now, when almost all meaningful script steps can be used server-side. ![]() Much better, safer, and correct in principle, solution was introduced with the release of FileMaker Server 9, the first version that allowed creation of server-side script schedules. Robot machine is a stand-alone FileMaker Pro client constantly connected to the FileMaker Server and regularly checking whether there is a task ready to perform. In the history, this need led to implementing a solution well known as a “robot machine”. But it was the FileMaker Server 13 that finally made this idea easy to implement. The idea of being able to off-load time consuming tasks from FileMaker Pro to FileMaker Server is as old as the scripting abilities of FileMaker Pro, which were introduced with the FileMaker Pro 3 release.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |