launcher and runtime

[stefangs]

this is related to some exisitng posts, but different.

i want to have a launcher file that users can click to access the data on a server. but i also distribute my solutions as single user files with a runtime app.

now the launcher should open the local data file. but how do i know what the 'server' is called or what its IP address is?

[Søren Dyhr]

Hi Stefan!

But a bound runtime can not work as launcher...? Only full copies of filemaker can deal with a file which could contain the IP number of a hosted solution... It's done via the init script, the file can be closed right after the launch...

I just made a laucher by the book, and then bound it - an error then occurs, because the opening launcher tries to locate the remote file on the local drive, with a .USR extension - it simply wouldn't dream on using a protocol it's unaware of.

--sd

[stefangs]

hi soren,

you got me stumped... again!

if i try to talk to the remote file which isn't really remote, because it is sitting in the same directory as the launcher file, is that still considered network access?

if so, would it be feasible then to have a branching script that determines if we are using a real copy of filemaker or not and depending on the results try to access the networked data file on a remote server or a local data file in the same directory? seems to be a usable workaround.

[Søren Dyhr]

if i try to talk to the remote file which isn't really remote, because it is sitting in the same directory as the launcher file, is that still considered network access?

The only way you can talk to another runtimes data is via applescript ...

It would be something in the vicinity of this:

http://www.macosxhints.com/article.php?story=20020914091607912

What you then do is that your runtime starts a full version of filemaker which then begins IWP'ing which could be seen in the webviewer of the launcher, and as soon as you finish the session would you then terminate the IWP session.

The question is then why do it via the launcher at all when a compiled applescript is all it takes ... at a fraction of the size a language trimmed runtime would measure. You could perhaps build an interface to the applescript via this:

http://www.latenightsw.com/fs4/

But each user would then speak to the same solutions interface ... and it would be very near impossible to instate a record locking mechanism ensuring each users found sets really are the ones they ordered.

not and depending on the results try to access the networked data file

Data in a served file is not a file as such but instead a protokol ... since the one who serves a solution would not dream of having sharing turned on the folder where the solution might reside, because the filesharing and the protokol both seeks to adjust the data, and is the safest bet if you deliberately would corrupt a solutions data.

So even though you might provide you user with the IP address to the serving machine, can't you do much else than start an ordinary version of filemaker at the other end of the network provided permissions are given, and tell it to launch a solution with which you then can mirror it back to another file in your end of the matter, or you can look at the running Filemaker via VNC ... Filemaker Server have no Applescript interface to itself like a clientversion - it has no layouts shown at all, and applescript should be embedded in shellscripts to be runned, but it can't still say something to itself.

If you need to sit and fork the entire revenue a shared solution initiates, must the solution as such be migrated to Runtime Revolution/Valentina via FMProMigrator:

http://www.runrev.com/newsletter/april/issue24/newsletter1.php

But what if the client suddenly want to change a bit here and there, then would comprehensive measures be required to ensure you have thought about every thing, when a new version is rolled out - opposed to filemaker where none of the data inside the solution is moved anywhere, if sudden changes to layouts or relational structures are required.

Frankly would I suggest the client buys enough client versions of filemaker to get their business up and running up against FMS - I know you over the years have had a fair income on runtimes, but that doesn't mean I think filemakers runtimes are up to it at all - Dominic Goupil have settled on another direction which he calls "Groupware" ... other RAD tools are much more up to producing foilwrapped solutions.

--sd

[stefangs]

soren,

you are an endless source of insighful links and thoughts. i think i either need to wrap my head around the concept of coercing my modest user base into buying filemaker or supplying strictly single user solutions! what i've been doing up til now is sort of a database hermaphrodite!

yes, at least since filemaker v3, when the developer edition wasn't crippled in the ways it is now. but of course, that feature came with a steep price tag.

[Søren Dyhr]

The business model is by this questionable ... filemaker is perhaps a conveyer of shareware tools to some extend, I have for some time worked as subcontractor for a guy, who sisyphean embark on the hunch if only he would be able to nail those difference between webhosted IWP'ed solutions and the touch and the geniuine feel of an app, then would the road be paved with gold.

Admitted have he found ways to level out some of the issues, but as such are we still out in massive efforts to circumvent the original intentions with the tool as such. He pays me in a timely manner for the jobs I do for him, but his businessmodel doesn't give neither he nor me the steady cashflow or tasks it supposingly should provide.

Honestly do I still not think filemaker as tool is up to any of the present models for either software as a service or as tool to produce foil wrapped solutions, but it can't harm anyone if we put efforts into rethinking the entire gesture - with this in mind:

http://www.longtail.com/the_long_tail/2009/07/free-for-free-first-ebook-and-audiobook-versions-released.html

(Which is the outside US downloadable version of Chris Anderson's book "Free")

The US audience just put this link into http://tinyurl.com/y95478x and something should happen in your Itunes app.

--sd

[bruceR]

You're trying to violate FileMaker licensing requirements. I don't think the forum tolerates that.

[comment]

You're trying to violate FileMaker licensing requirements.

That's a serious accusation - what exactly is it based upon?

[Søren Dyhr]

I think he means this:

You are prohibited from using the Runtime with any middleware, application server, CGI, or other software or technology that allows more than a single client to access the Runtime. Furthermore, the Runtime and Runtime Solutions are prohibited from being used as clients of any FileMaker product (e.g. the Software, FileMaker Pro or FileMaker Server).

And yes I tried to see what happened to a served linked file, where the test solution then asked what it would supposed the linked file should be known as in a bound solution.

I admit to not having waved sufficiently with the license flag!

But it gets more serious, I then wrote this:

The only way you can talk to another runtimes data is via applescript ...

Yikes ... show me the door - please! I admit to have written an applescript which can do something to a runtimes data, and could not envision any problems in including these as embedded in one runtime although it might speak to another ... have I ever made and sold such a scheme to anyone - certainly not!

But the very thought is heretic, similar to checking cars in a carpark for unlocked doors ... or believing newly cut sheep could exhibit same virtues on the invisible side on their body, where only threspassing could establish the fact ... unless the sheep suddenly turns around, and reveal the unknown side.

Strictly speaking can't you look at IWP'ed page in webviewer of a runtime without voilating this:

Runtime Solutions are prohibited from being used as clients of any FileMaker product

This even include Filemaker Inc.'s page!

--sd

[comment]

IMHO, "getting data from" and "being a client of" are two different things.

[Søren Dyhr]

But I could easily see that you need to be versed in law to make proper distinctions ... next issue I came to think of, is the use of Facespan which apparently often is used for:

FaceSpan is often used in creating AppleScript CGIs to take advantage of its built-in FIFO (first in first out) capabilities. When multiple CGI calls are sentto a normal script application, the last person to call the application gets their results first (this is called LIFO, or last in first out). This order of execution isn't desirable in a CGI environment, so it's often worthwhile to save your CGI script applications as FaceSpan stand-alone applications to get FIFO performance.

http://www.amazon.com/Applescript-Internet-Visual-QuickStart-Guide/dp/product-description/0201353598

So the violation is stumbling near!

--sd

[comment]

LOL, if you insist on pleading guilty, be my guest…

[Søren Dyhr]

The purpose was different, tracing a facespanned runtime from Bruces hand could be possible??

--sd

[stefangs]

although this has gone a bit off topic, i'm happy to say that after nearly 10 years on the forum, it looks like i created my first hot topic.

it appears that there are all kinds of tools out there that allow you to network runtimes (although that wasn't my question to begin with). it's a bit like drug laws where i am. you're allowed to own certain drugs, but you're not allowed to sell them or take them. which is appropriate because filemaker is sort of a drug itself!

[Vaughan]

Runtimes *can* legally be networked: there is an option to do so in FileMaker Server.

However, once networked they have to accessed with FileMaker Pro client software... so we're back to using FMP client and not the runtime engine.

[comment]

That's like saying:

Cars *can* fly - if you equip them with wings.

However, once they are equipped with wings they are airplanes, not cars... so no, cars cannot fly.

Anyway, in the FMP License "Runtime" means "FileMaker Pro Advanced Runtime engine, which is created by the Application" - not database files included in a Runtime Solution.