Do I understand correctly the “.app” capability will soon be (or is already) disabled? If so, which version?
As runtime (.app) gets deprecated, the word “App” is now used to refer to any solution built on a Claris platform
Do you mean the runtime capability? That's still in FM18. But it has been marked as deprecated so it will be removed in one of the future versions.
The topic title is a little misleading. The .fmp12 extension has been around since FileMaker 12 so coming up to a decade. The runtime ability has nothing to do with the filemaker extension.
It's been brought to my attention that more than one user is confused with seeing .app and .fmp12 files but they're both referred to as "apps" and especially by current marketing efforts.
I found the combination of title and post content confusing. The clarification in a subsequent post helped me make better sense of this. Without that post, I'd still be confused by the mention of the fmp12 extension.
Hope this may help -- it's not any critique of the topic being discussed, just some feedback about how I wasn't confident about my understanding of the content.
"As runtime (.app) gets deprecated, the word “App” is now used to refer to any solution built on a Claris platform "
Is this declaration a fact from Claris and will stand the test of time?
There is no clear-cut definition. Wikipedia has an interesting article.
A fmp12 file is not an application in the sense of an executable. It contains code that is interpreted for execution.
We could call it an application in the sense of a piece of software that serves a specific purpose.
In the short term it's nothing but confusing. Claris' marketing has been referring to solutions built on the platform as 'apps' for a number of years now but the FM Cloud Essentials is the first time that this notion actually translates to something real. With its limitation to host only 3 'apps'.
My fear is that this just leads to developers building single-file solutions and that then very often leads to scalability, disaster recovery and business continuity problems. Plus often performance problems.
Ideally we'd need one more object in the platform: the app-level, the solution-level. Something that can span multiple files and where you'd for instance be able to configure the security scheme for all files in a solution. That way we could uniquely define what an app is.
It comes with an interesting price and limitations. The ‘3-apps’ frame covers a lot of use cases. There might be some refactoring required when solutions grow. The strategic part in strategic software development becomes all more important. That’s what small shops initially do not care enough about.
I was in the midst of creating what I intended to be a simple post. I then realized it had turned into a diatribe so I stopped myself.
To be blunt, Claris has a marketing crises, IMO. A crisis because this particular marketing effort is happening at the time of management changes, especially. The worst time to appear confused or confusing about any thing to any one.
More later, time permitting.
We won’t change a thing. Let’s focus on the technical matter
Nope. It is my attempt to rephrase your previous title to have it express concisely the topic of the thread based on the first few clarifying posts you made to others at the beginning of the thread.
Forget separation model or cmv approach in that format.
Do you know if independent consulting developers will be allowed to access their clients server/cloud account?
Same as with the regular FM Cloud: as long as they assign you a slot of their available licenses and add your FM id to their users, you're in. Depending on how close they are to the upper limit of their license pool this may mean they have to temporarily bump one of their actual users off the licensed list.
That dance they (Claris) force people into is really a pain point. I know Cloud is only recently introduced, but I'm hoping the "patch tool" that was part of the roadmap would let us circumvent this altogether in the future.
I would keep your focus on how to best use the DMT. Though I realize it doesn’t fit exactly what you are referencing. Remember, in whatever form, that tool will be a v1 release.
The DMT implies changing the file altogether. To date, it does not play friendly with FM Cloud. I am not aware of any changes to the DMT or FM Cloud that would improve that sensibly. I keep my fingers crossed the patch tool will be in line with the "cloud first" vision and not something they will have to figure a way to have it play nice with FM Cloud "after the fact".
In what way? How and where the file is deployed doesn't matter when using the DMT since you have to run it on local files anyway because it works with the file at the filesystem block level.
If you are talking about the larger set of operations to download and re-upload the file, then I agree. What we need here though are updates to the Admin API so that we can automate moving files about.
Yes, that's what I meant when I said the DMT "implies changing the file altogether".
I am simply hopeful for a method that would allow us to deploy our modifications to a live file without requiring a dedicated user the customer is paying for.
I do understand it requires some form of authentication, but I feel it would be best if the design did not require that authentication to deplete the customer's license pool.