Scripting in upcoming IMatch versions

[ben]

So, i still don't get the whole picture.

The embedded IMWS inside IMatch is not accessible from scripts running outside of IMatch. I will probably setup something that allows this, with restrictions. We need this to use debugging tools in browsers. The App Panel has no built-in debugger (Windows restriction, not mine). But I need to prevent not-so-honest users from abusing IMatch as a cheaper replacement for IMWS by running IMatch and a separate web server on the same machine.

So, probably you won't be able to access IMWS functionality from external scripts when you don't have IMWS.

Ok, i partly understand why you decided this way. But maybe you can come up with a solution that satisfies all of us and your needs at the same time.

So, if i run a script from outside iMatch and use IMWS functionalities, then i cannot access the iMatch internal functions?
For example, get all currently selected files in the file window.

That wouldn't be good, since you could only use external functions or iMatch internal functions. But not both at the same time.
Maybe a compromise would be to allow external scripts, that have been called from inside iMatch (e.g. from the favorites menu) to access iMatch internal functions.

Ben

[Mario]

Maybe a compromise would be to allow external scripts, that have been called from inside iMatch (e.g. from the favorites menu) to access iMatch internal functions.

Impossible to know. Much to limited and error-prone anyway.

So, if i run a script from outside iMatch and use IMWS functionalities, then i cannot access the iMatch internal functions?
For example, get all currently selected files in the file window.

No. IMWS has no file window. IMWS is independent from IMatch.

We would need a way to allow external processes to access the IMWS built into IMatch. This has access to IMatch-UI specific features (like the selection in the file window)
We need something like this anyway in order to allow users to use external web browsers to test scripts they want to run in IMatch. To use the debugger and other cool developer helper tools.

I will have to come up and add some measures to prevent users from abusing IMatch as a cheap replacement for IMWS of course.

But I wonder how many people out there really would like to run external processes (e.g., PowerShell scripts) and connect from them to the embedded IMWS instance inside IMatch. Is this worth the extra work and complexity? How many people will need this? 2? 20? 50?...

[akirot]

Nobody can know and/or  therefore knows how many users write or use scripts.
If Mario introduced an alternative scripting approach (parallel to the existing one for a certain period of time) so users can migrate their scripts would be evolutionary.
Mario confirmed the next (scripting) version will not provide write access.
Thus he actively locks out all users whose workflow is built on this feature - i.e. cutting his own revenues.
I hope he rethinks his approach (even Adobe once rolled back their "improved" Lightroom import :-) )

[Mario]

Mario confirmed the next (scripting) version will not provide write access.

Wrong. I will add write-back features very soon,

Thus he actively locks out all users whose workflow is built on this feature - i.e. cutting his own revenues.

Lets say I would have to pay 6,500 US$ for a new scripting version and one year distribution license. Now count how many users I may "loose" by not providing Basic scripting anymore. If I lose less than 6,500 US$ I make a profit. My estimate is than maybe 20 users will be affected more or less by the scripting features which will not longer be available.

[scw2wi]

Although I've read about IM6 in the Forum and about IMA also on the website I have still some questions.

What I understood so far is that there will be a hard cut from IM5 to IM6 which means, that in IM6 BasicScript will be replaced by JavaScript.
I have developed some BasicScripts which are mandatory to me and although my JavaScript knowhow is not the best, I'm sure I will be able to convert all my Scripts - if possible.
I have also developed one JavaScript AppPanel but hopefully this need not be converted.

I did not fully understood the difference of IMA and IMWS but I will explain what I understood, maybe it's correct.
IM6 uses IMWS to access the DB but only localy, IMA also uses IMWS to access the DB but can do that also from remote.

I cannot say that I'm very happy about this change but I understand the reason and I aggree that it was a good decision.
It the moment I am still scared about my migration effort but I'm sure, that at the end I will be happy about many new possibilities.

Since I know that this forum here provides the best support I've ever seen, I am confident that I will do the migration in reasonable time.
My only concern is, will it be possible that I run IM5 beside IM6 on my PC during the migration process and my request to Mario is, please make it possible.
I would also pay an extra price for an IM6 VBScript Plugin, if this will be the option for the view Script-Users to migrate their scripts.

I will start learning by comparing the old BasicScripts from Mario with the new equivalent JavaScripts coming with IM6.
What I understood is, that COM will not be supported in IM6 any longer - well I'm not using this COM feature as of now (I've tried, but couldn't bring it to work).
Are there any more features that cannot be migrated from IM5 BasicScript to IM6 JavaScript?

I have written one script that remembers me each time I'm closing IM and any writeback request is still open.
This might be also a candidate for a no longer supported feature.

Walter

[Mario]

IMatch Anywhere (IMA) and IMatch are separate products.
IMatch WebServices (IMWS) are a key component of IMatch Anywhere. By running IMWS on a PC you can make your IMatch databases accessible to apps and other web services.

IMWS is a programming interface for IMatch. Similar to the object model I've designed 10 years ago and which made IMatch database objects accessible from Basic.

The object model was closely linked to WinWrap Basic and it caused a lot of maintenance horrors over the years.

IMWS, however, is based on modern web standards. It makes IMatch databases accessible locally and remotely for all programming languages and tools which can use web services. The easiest way to access IMWS is JavaScript, but you can also access it from tools like curl or programming languages like Python, Java, C#, VB.NET or PHP. And you cannot only use it from software running on Windows, but also from software running on the Mac or Linux. Only IMWS itself is Windows-bound.

It makes no sense to maintain two development models for IMatch. The old object model hence will go. Way too expensive (annual license cost). To complex to maintain and support.

IMWS is all we need from now on. I will integrate a special "embedded" version of IMWS into IMatch so we can use it for the App Panel, the Map Panel and other features.


Some proprietary things, e.g. using COM components or automating external applications (e.g. controlling Microsoft Office) are not supported by JavaScript. And hence it will not longer be possible to do this directly from within IMatch. I doubt that this change will affect more than a handful of users. If at all.

Of course, thanks to the openness of IMWS, you can handle such scenarios still.

In IMatch 5 you creates a Basic script which used the IMatch object model to access database content. Then you wrote the code which dealt with the external OLE application, e.g., automating Word to create documents.

In IMatch 6 you would write the same code, but you have total freedom when it comes to your programming language. For tasks like this, Windows Powershell, the programming language and environment which is an integral part of Windows, is ideal. It's always available, free, supported. Has an integrated IDE with a debugger - and all much better than what we had in IMatch 5. I use PowerShell scripts to automate many things.

And to access IMatch database contents from a PowerShell you would just access IMWS. PowerShell has methods to exchange data with web services.

I have at this time not decided if I will support such "external invocation" scenarios with the built-in IMWS or if this will require a separate "full" IMWS license. Since the HOME edition of IMWS is sold for spectacularly cheap US$ 45 I don't see that this should cause a lot of grief.

[Mario]

Just to give you an example:

PowerShell is a part of Windows. And you can access IMWS with a single line of code from it. Whether the IMWS you access runs on your local computer or on a computer on the other side of the planet.

The /info endpoint in IMWS returns information about IMWS and the loaded database. The response is formatted as JSON data, which is automatically handled by PowerShell.

This small script calls the /info request and displays a) the full returned data and b) selected elements:

Code Select Expand


$data = Invoke-RestMethod -Method Get -Uri http://your-pc:8081/info

Write-Output $data

Write-Output ("edition: " + $data.edition)
Write-Output ("version: " + $data.version)
Write-Output ("Database name: " + $data.database.filename)


Copy/save this code into a file on your disk with the .ps1 extension. You can then run it by double-click.

Even easier:

Start PowerShell by search for PowerShell and then starting the "PowerShell Desktop App".
Copy paste this line:

Code Select Expand

Invoke-RestMethod -Method Get -Uri http://your-pc:8081/info

and press <Enter>. This connects to IMWS; calls the /info endpoint and displays the result on screen.

Note:  You need to change http://your-pc:8081 to the computer name or IP address of your IMWS installation.

[scw2wi]

Mario, that all sounds great, but I need to learn it by doing before I really understand all the differences and advantages.
First I will wait till IM6 comes out and during this waiting time I will hope that you find a good solution for a smooth migration phase.
I will also buy IMA since this WebViewer is exactly that kind of Application my wife always asked for.

Walter

[Mario]

Mario, that all sounds great, but I need to learn it by doing before I really understand all the differences and advantages.
First I will wait till IM6 comes out and during this waiting time I will hope that you find a good solution for a smooth migration phase.

This is a new programming paradigma. Switching from BASIC to JavaScript is a leap of 20 years  . Thankfully there are far more people out there who know JavaScript and HTML than there are people left who speak BASIC. This means you'll find tons of superb tutorials and many, many videos on YouTube which demonstrate things.

The IMatch Developer Center has tutorials and many sample scripts already. Just today I've added two scripts which show how easy it is to access your IMatch database from Windows PowerShell.

I will also buy IMA since this WebViewer is exactly that kind of Application my wife always asked for.

Ye-hah! Very good. I'm sure your wife will enjoy the simplicity and snappy performance of IMatch WebViewer - from whatever device she's going to use.
You can immediately get your hands wet with some JavaScript programming and IMWS.
Check out the https://www.photools.com/imatch-anywhere/imatch-anywhere-developer-center/ for examples and links to tutorials on HTML and JavaScript. It's actually fun, especially since you get results so fast and the developer tools in modern web browsers are so good.

[ben]

Copy/save this code into a file on your disk with the .ps1 extension. You can then run it by double-click.

Can we then call this script from the favourites panel inside iMatch?

I have at this time not decided if I will support such "external invocation" scenarios with the built-in IMWS or if this will require a separate "full" IMWS license

I hope for the first option 

[Mario]

Copy/save this code into a file on your disk with the .ps1 extension. You can then run it by double-click.

Can we then call this script from the favourites panel inside iMatch?
[/quote]
If you have a shortcut you should be able to call PowerShell scripts from the Favorites panel. Or do you mean that you want to call this script from the fav panel and it should connect to the running IMWS inside IMatch? This would only work if I allow external access to the IMWS embedded in IMatch - and this has security and commercial implications.

I have at this time not decided if I will support such "external invocation" scenarios with the built-in IMWS or if this will require a separate "full" IMWS license

I hope for the first option 
[/quote]
Consider the massive amount of work that went into developing IMatch Anywhere. Almost a year of my life. And now people are bickering about the few bucks I charge for it.
Heck, you pay a lousy 45$ for a perpetual 2 concurrent user license. The cheapest competitor charges 3 times as much per user per month.
I would say if you have the need to access IMWS from external scripts, this is considered professional use and should even demand a PRO IMWS license. Don't you think?

[thrinn]

Mario, thank you for sharing so much information regarding the future of IMatch!

My understanding from reading this post (and other related discussions) is:

• An IMatch 5 App will presumably not work in IMatch 6 because the IMatch5 object model will be retired. Instead of using something like the IMatchLib wrapper to the underlying Object model, use of the provided Web Service endpoints will be the way to go.
• An HTML5/JavaScript app written for IMWV will (most likely) work inside IMatch 6. Presumably in the app panel or something similar.
• Functions to modify the database will be (might be?) only available in IMatch 6, not in IMWV. Therefore, some apps written to run inside IMatch 6 will not work from "outside" if they use some of these functions.

Are these assumptions correct?

(One a side note: I am already pretty sure I will upgrade to IMatch 6 when it is available. If an IMA license is required to use some functionality regarding scripting, this is totally acceptable for me. I think the IM/IMA bundle is very reasonably priced for the features offered.)

[Mario]

An IMatch 5 App will presumably not work in IMatch 6 because the IMatch5 object model will be retired. Instead of using something like the IMatchLib wrapper to the underlying Object model, use of the provided Web Service endpoints will be the way to go.

Correct. The old IMatch 3 - 5 object model will be gone for good. The programming interface provided by IMWS (endpoints) is the way to go.

An HTML5/JavaScript app written for IMWV will (most likely) work inside IMatch 6.

All scripts written for IMWS will also work in the IMatch 6 App Panel.
There will be only one programming model that works for both internal and external scripts, across all programming languages and across all operating systems and devices - IMWS.

If you write a script to run "inside" IMatch, it will have access to additional endpoints which are not available (or useful) for the stand-alone IMatch WebServices.
The "embedded" IMWS in IMatch will provide methods to access the file window, for example.

Functions to modify the database will be (might be?) only available in IMatch 6, not in IMWV.

Wrong. Currently IMWS is read-only. It just does not offer methods to write back to the database right now.
But that will change real soon. It will get methods to update files, to change metadata, categories, collections, ratings, labels, etc. Functions to create, mode and rename. To upload files. And of course, when IMWS learns something new, it will be available for the standalone IMWS and also the IMWS embedded in IMatch. Making IMWS better means also making the programming environment for IMatch better.

But, IMWS adds some additional complexity. In IMatch, only one user can access a database in writable mode. If you change metadata, this affects only you at that moment.
But IMWS has been designed from the ground up for concurrent multi-user access. If one user changes metadata in a file, this may affect 20 other users. The categories (@Keywords!) they see in their browser may no longer be valid. Or other data-driven categories. Metadata in many files may change (versions!)... IMWS must also prevent that two users change the metadata for the same file at the same time. Or try to move a file another user has just deleted.

This has to be manged by IMWS by check-out mechanisms and locks and similar technical things. This is why I decided to ship the initial version with read-only features only. And we can do a lot with that already!

When IMWS 2.0 comes out it will allow you to change IMatch database contents (also from within IMatch of course).
And this may mean that many users don't need IMatch Anymore - only IMWS and a web browser. Especially in institutional and corporate environments.
Modern cameras have Wi-Fi and can upload files to web services. Why not upload files from your camera directly into your DAM...

[axel.hennig]

And this may mean that many users don't need IMatch Anymore - only IMWS and a web browser. Especially in institutional and corporate environments.

Now, I'm a little bit afraid (for the long term). This sounds to me that in the (perhaps far) future IMatch won't be continued and there will be only IMatch Anywhere left...

[ben]

If you have a shortcut you should be able to call PowerShell scripts from the Favorites panel. Or do you mean that you want to call this script from the fav panel and it should connect to the running IMWS inside IMatch? This would only work if I allow external access to the IMWS embedded in IMatch - and this has security and commercial implications.

That's fine. I meant the solution via a shortcut. You already mentioned, that you have to think about a good solution for "handling external access to the IMWS embedded into iMatch". So, i'll just wait until you settled all your ideas 

I hope for the first option 

[..]And now people are bickering about the few bucks I charge for it.
Heck, you pay a lousy 45$ for a perpetual 2 concurrent user license. The cheapest competitor charges 3 times as much per user per month.

No, i didn't mean that nor did I say that.
I am sorry if you misunderstood it.

[ubacher]

I am slowly getting a better understanding of IM6 and IM Anywhere.
And also of the changes to the scripting environment. Having to use a separate computer
to develop scripts on IM6 while running IM5 in "production mode" will be a hassle.

I do however still have a question about the Web Viewer:

IM Web Viewer should just be an html file containing the right (javascript) code to let you query the server.
Logical would be that this html file ("page") be delivered by the server (IMWS) as the home page.
I don't see why IM web Viewer is/can be a separate "program".

[Mario]

Now, I'm a little bit afraid (for the long term). This sounds to me that in the (perhaps far) future IMatch won't be continued and there will be only IMatch Anywhere left...

Would that be a problem?

You want a DAM. With the features of IMatch.
If you can get all this in your web browser and you can access your DAM not only from Windows, but also from Linux, iOS and Android, why not? Even, if you want, from anywhere in the world? Would that not be much more flexible and useful?

Maybe you can use your DAM directly from your camera some day. Camera vendors are integrating more and more smart phone tech in their camera models - and why not run an "IMatch app" there that allows you direct upload into your IMatch DAM?

If you read my comment again, you will see that I explicitly mentioned corporate and institutional users. That's the main audience for a browser-based DAM at this time.
One PC that runs IMatch Anywhere gives 5, 10 or 50 users access to an IMatch database, from any device and location. So much easier now.

When IMWS gets features to update the database, to edit metadata and categories and to upload files, I can enhance IMatch WebViewer to become "IMatch for Web" or something. With the features it has now, but also features to edit rating & labels, metadata, keywords and categories.

And that may be sufficient for many users already.
I know that many IMatch users buy IMatch Anywhere to allow their family and friends to access IMatch databases using a simplified user interface. That also works on all devices and operating systems. They don't need all the advanced features of IMatch for Windows. They just want to find and view and present files.


I write all this while I work on IMatch 6. It will bring several major features and many enhancements in small areas.

From my point of view, IMatch for Windows and IMatch Anywhere will co-exist for a long time. No fear.

IMatch will embrace IMatch Anywhere technology to give us powerful and modern scripting. To allow me to integrate current web technologies, 'social' technologies, access cloud-based services, e.g., for face recognition, object and text recognition and similar.

IMWS will quickly evolve to include features to update the database. This will benefit both IMatch for Windows and all users who prefer the combination of IMWS and a browser-based user interface.

[axel.hennig]

Now, I'm a little bit afraid (for the long term). This sounds to me that in the (perhaps far) future IMatch won't be continued and there will be only IMatch Anywhere left...

Would that be a problem?

You want a DAM. With the features of IMatch.

That's correct, but:

I know that many IMatch users buy IMatch Anywhere to allow their family and friends to access IMatch databases using a simplified user interface. That also works on all devices and operating systems. They don't need all the advanced features of IMatch for Windows. They just want to find and view and present files.

My fear was just, that in the (hopefully far) future there will be only one product (NOT IMatch for Windows) with less features. Perhaps (I'm not a programmer, so I don't know) because "software for browsers" can't have as much features as "normal software".

From my point of view, IMatch for Windows and IMatch Anywhere will co-exist for a long time. No fear.

Puuuuh, that's a relief.

[Mario]

because "software for browsers" can't have as much features as "normal software".

Not true.

The big internet companies (Google, Facebook, Apple, Microsoft, Amazon, ...) are driving the development of web technologies and browsers. What is now possible with HTML and JavaScript was unthinkable just two years ago.

The development cycles for JavaScript/HTML are super-fast, which means software can shipped very often, improved, shipped again.
There are powerful tools and frameworks available, and a huge world-wide community of programmers.
Everybody with a text editor and an Internet connection can learn how to program in JavaScript and HTML, and then do stuff.

Microsoft has written their web development tool "https://code.visualstudio.com/" in JavaScript. Software shipped by Amazon or Spotify is written in JavaScript. Many other software too. The user usually don't even notices this (or cares). They are all using the "Electron" software framework which allows us to create "real" applications (written in JavaScript and HTML) for Windows. Mac and Linux. Soon Android and iPhone too I guess.

Needless to say that IMWS works well with all these tools. Which means you (or I) can use all these exciting frameworks and tools in scripts written for IMatch 6 or in scripts/apps written for the standalone IMWS product. I have great plans for that. IMatch 6 will benefit a lot from the new possibilities - starting with a better Map Panel.