Ceasing the current Visual Basic scripting implementation for an upcoming IMatch version has been discussed at some places. I understand why Mario is intending the introduction of new techniques and fully support his approach.
However, I use scripts around versioning (which extend IMatch's already rich functionality) and need them for the management of my images.
If they don't work on a new IMatch version this clearly would be an upgrade blocker.
I'm fine with learning new programming languages and techniques and using them for new scripts thus supporting future developments.
Mario, can you confirm existing scripts will continue to work (on an "as is" basis) on an upcoming IMatch version?
Will the new environment give access to the same methods etc. as the current implementation?
QuoteMario, can you confirm existing scripts will continue to work (on an "as is" basis) on an upcoming IMatch version?
No. IMatch 6 will have no Basic scripting anymore.
I will not renew my license for this 3rd party toolkit anymore. Its old. Its expensive. The GUI support is not good.
IMatch versions prior to version 6 will receive no updates anymore and no support 6 months after IMatch is released. The Basic scripting engine in these products will continue to run, unless a Windows update or similar external change breaks the functionality.
For IMatch 6, all scripts will need to be rewritten using IMWS technology, in HTML and JavaScript.
I will do that for the few scripts I have provided (mostly import and export plug-ins) of course.
All other scripts I ship with IMatch are sample scripts which demonstrate how to the the object model etc.
These will be removed. IMatch 6 and IMatch WebServices use the same programming model and hence there will be one documentation and one sample script set for both.
I'm already working on that.
In addition, the
embedded IMWS in IMatch will support a few additional programming interfaces. This includes functions to access the current file window ("get me all selected files"), support for reading and writing files, standard windows dialog boxes, IMatch dialog boxes and suchlike.
I try to keep it slim, though. There are not many people out there who write scripts for IMatch. There were more for IMatch 3, but IMatch 5 is so rich in functionality that not many scripts are needed. Many users out there don't even know about scripts at all. It makes no sense to spend weeks to develop something that will be used by 2 people out there.
QuoteWill the new environment give access to the same methods etc. as the current implementation?
In principle, yes. IMWS offers a rich set of "endpoints". To see what's offered, open the "Discover IMatch WebServices" from the IMatch WebViewer gear menu. If you don't have IMatch Anywhere, you can use the TRIAL edition or wait until IMatch 6 is released.
IMatch 6 and IMWS use the same programming tools and programming model. What works in IMWS will also work in IMatch. IMatch will just have some more methods which are available for scripts running "in" IMatch.
Mario - what sort of time scale for IM6?
Quote from: DigPeter on January 18, 2017, 12:43:08 PM
Mario - what sort of time scale for IM6?
Sorry, but I don't mention fixed dates out of principle.
Too much can happen. I can meet a technical challenge that costs me a month to overcome...and all dates would be voided. Users would be disappointed or angry etc. No good.
I'm currently working on IMatch 6 most of my time. Things are going well. I aim at the 2nd. quarter 2017.
Thanks Mario - that is all I wanted.
For me the scripts are what makes IM so powerful. And I seem to recall that you frequently turned down requests
saying that if this or that functionality is needed one should /could do it with a script. (Which I did.)
Now the problem is converting the scripts to javascript - But can I do this - can I run the old version (basic) and the new
version together? I need to use the old IM while the scripts are still not converted and the new one for the conversion.
I see a logistics problem. Or will you provide a V5 which has both scripting engines for the purpose of converting?
Since I don't know Javascript I will need a lot of examples to get me going and I will need time to learn so I can do the conversions.
I will remove the scripting engine from IMatch 6 - actually it's mostly gone already. Makes things quicker and removes a lot of code.
I doubt that you can run both IMatch 6 and 5 on the same system, because not only is the IMatch 6 database format 'newer' (to incorporate the changes I make for IMatch 6) but also the versions would need to share settings, plug-ins, configuration files, settings database, .... Way too hard to keep all this synchronized.
Better prepare to have a second PC to run the 5.5* version of IMatch and one on which you run the IMatch 6 version.
I don't know how many scripts you have created or what these do so I cannot comment on that.
You can already start programming now, using IMatch WebServices to access your database contents.
All you need is a text editor (e.g. Notepad++ or the free Microsoft Visual Studio Code https://code.visualstudio.com/Download).
Your browser (recommended: Chrome or Firefox) have built-in developer tools <F12> key. They show you what data you send, what data comes back from IMWS. You can set breakpoints in your code, just like in the Basic editor in IMatch. Just a lot faster and easier.
The endpoints (programming interfaces) of IMatch WebServices are documented directly in IMatch WebViewer. Gear menu > Discover IMatch WebViewer. The code examples work with your live database and return real data.
More documentation and sample code for using IMatch via IMWS is in the making. I will publish things in the Learning Center when I finish something.
If you have never used JavaScript, start here:
http://www.w3schools.com/js/
@John Zeman
I hope you are following this, John. I find your script "The Ultimate Image Description Writer" very useful. Will you be converting it to run with javascript?
Peter if I was a few years younger I would, but I'm getting to the age now where learning something new is far easier for me to say than it is for me to do. So going by what I'm reading here I'll probably stay with version 5.
It pains me to say that because I really love IMatch but version 5 is doing everything I want IMatch to do and I have to keep my own reality in mind.
Maybe you can send me your script so I can have a look at what it does?
Does it things the Metadata Panel or the Keywords Panel cannot do?
IMWS is currently read-only but naturally I will add features to update the database (metadata, categories, ...) over time. This will allow users to update metadata in their browser and of course also in IMatch scripts.
I know already that I can easily port the CSV import, Import Metadata into Attributes, HTML Report, KML Esport and maybe I will even do the Juicebox export.
Mario that script is listed in the Script Gallery here in the forum, it's called The Ultimate Caption Writer. Below is a copy and paste of what it can do.
- Edit the current caption (description).
- Actively monitor and show the total size of the current caption as you type.
- Copy the current caption to the clipboard.
- Replace the current caption with the text on the Windows clipboard.
- Compares the captions of the selected images to see if they are identical.
- Find specific text in the captions of the selected images.
- Replace specific text in the captions of the selected images.
- Append text to the end of existing captions of the selected images (even if the existing captions are different).
- Pre-pend text to the beginning of existing captions of the selected images (even if the existing captions are different).
I see. Some of these things can of your be done in the Metadata Panel (1-5).
The find text in caption, replace, append and preprend are specialties. I don't see a frequent use for those but I understand that having this may be helpful for some users in some situations. I don't recall a feature request for this, but a "more advanced" editor (e.g. in a popup) for the Metadata Panel would not be so hard to do.
And of course this is also an ideal beginner example for working with IMWS. As soon as I have the "updating data" features implemented. And it would look real nice, because of the HTML we can use to create the user interface for it.
Quote from: Mario on January 19, 2017, 03:33:42 PM
I see. Some of these things can of your be done in the Metadata Panel (1-5).
The find text in caption, replace, append and preprend are specialties. I don't see a frequent use for those but I understand that having this may be helpful for some users in some situations. I don't recall a feature request for this, but a "more advanced" editor (e.g. in a popup) for the Metadata Panel would not be so hard to do.
John produced this script early in the life of !M5, so filled a need of some people, who therefore did not need to request it in the Forum.
The metadata panel can be used to change Descriptions of many files simultaneously when they are all the same. I find John's script useful particularly for amending several files with different descriptions simultaneously. The last 3 of John's list are particularly helpful in this respect.
I would welcome such a script to be built into future versions of IMatch.
QuoteI would welcome such a script to be built into future versions of IMatch.
I recommend adding a feature request then.
Quote from: Mario on January 18, 2017, 04:17:06 PM
If you have never used JavaScript, start here:
http://www.w3schools.com/js/
Neat. Time to learn a new computing language, I've started on the tutorial this afternoon.
Quote from: Mario on January 19, 2017, 04:37:08 PM
QuoteI would welcome such a script to be built into future versions of IMatch.
I recommend adding a feature request then.
Will do, but I cannot find the IM Feature Request board - only for IMA & IMW.
Quote from: DigPeter on January 19, 2017, 05:57:41 PM
Quote from: Mario on January 19, 2017, 04:37:08 PM
QuoteI would welcome such a script to be built into future versions of IMatch.
I recommend adding a feature request then.
Will do, but I cannot find the IM Feature Request board - only for IMA & IMW.
The IMatch feature request board is the one.
Quote from: JohnZeman on January 19, 2017, 02:08:07 AM
So going by what I'm reading here I'll probably stay with version 5.
+1
These are some of the methods I use:
Application.Database.SelectFoldersDialog(...)
QueryFiles (...)
RemoveFile(...)
AddFile(...)
Database.CreateManualVersion(...)
Database.DeleteManualVersion(...)
I consider the latter ones as core functionality.
If this core functionality gets lost with a next version of IMatch I can't and won't upgrade.
Visual Basic itself might be abandoned but please show an upgrade path.
Personally I don't need IMA.
Slightly off topic:
I don't have real performance issues (with currently about 100.000 images and many many categories - can't count them right now because I'm not at my desk).
The map panel still has the "old" glitch of sometimes not showing tiles because of "possible server overload" - I never experience this with geosetter (which is my fallback for these situations). One doesn't need web access to the DB to fix this.
The viewer still is outperformed by the fastpictureviewer (unfortunately it can't be integrated closely because it works directorywise). This will not improve with webaccess.
Quote from: Mario on January 19, 2017, 03:33:42 PM
And of course this is also an ideal beginner example for working with IMWS.
Yes.. examples on how to currently interact with the scripting features would be nice.. I've read the documentation that displays all the "methods" for interacting with the IMatchviewer.. but still can't figure out how to setup an HTML file with the necessary JS/css files to interact with the database and display data.
For example - lets say I have marked 10 images as Favorites in IMA via the "heart" icon.... now, I want to write a script that locates these items and creates a filename list with paths... don't see how that's possible. Also, is there a ways to add our own "panels" to IMA via scripting as we can do now with the Funtoy?
Just trying to figure out how scripting currently works and what kind of things can we do with it. thx!
QuoteThe viewer still is outperformed by the fastpictureviewer
Interesting. I measure the opposite. IMatch uses hardware-based DirectX rendering. FPV cannot be faster. But IMatch does a lot of stuff FPV does not, including metadata display, collections and stuff. If you need the maximum speed, turn of the stuff that holds back IMatch.
QuoteThe map panel still has the "old" glitch of sometimes not showing tiles because of "possible server overload" -
I even get that sometimes from Germany when I directly work with GeoNames.org and OpenStreetMap. But since you are using GeoSetter you have an alternative for this situation and don't need IMatch. Or get yourself a paid account and support the OpenStreetMap and GeoNames community projects. This gives you access to the faster servers and you most likely will never face a timeout again.
QuoteIf this core functionality gets lost with a next version of IMatch I can't and won't upgrade.
You don't need to upgrade. IMatch is no subscription. It won't stop working when you don't pay. I will no longer support it of course and the Basic scripting may break with a Windows update if it is not maintained anymore.
The few scripting methods you mention are low-end stuff. I will of course provide access to relations (IMWS already does the full functionality, but only read-only) but it may not be in the first version of the API. I will concentrate on standard stuff first. Not many users will need to create or remote manual versions in the first fee weeks.
QuoteYes.. examples on how to currently interact with the scripting features would be nice..
Of course. As I wrote yesterday I'm already working on the IMatch Developer Center web site. And samples. And tutorials.
IMWS is already documented.
Just start with a JavaScript tutorial that explains how to use a web service.
I mentioned a good learning web site yesterday.
Accessing a web service takes 5 lines of JavaScript. Once you have get that to work, pick one of the methods of IMWS, e.g. the /info endpoint which returns information about IMWS and the database.
I used that for the first example script in my tutorial (not yet accessible for the pubic).
The IMatch Anywhere Developer Center (https://www.photools.com/imatch-anywhere-developer-center/) has opened today.
Check it out for tutorials, resources and some initial sample scripts.
Woot! That was fast... thx Mario... off to play!!
Well Mario, I shouldn't be surprised that you keep surprising us. The Developer Centre is great and could become a very valuable resource.
When do you have a break ? :) :) :)
Quote from: hro on January 21, 2017, 09:05:57 PM
Well Mario, I shouldn't be surprised that you keep surprising us. The Developer Centre is great and could become a very valuable resource.
When do you have a break ? :) :) :)
This was a work in progress for some time.
I will add more examples as I write them. The examples will also be test cases for me, during the development of the scripting system for IMatch 6.
Quote from: Mario on January 18, 2017, 09:45:00 AM
For IMatch 6, all scripts will need to be rewritten using IMWS technology, in HTML and JavaScript.
Under the existing basic scripting engine in IMatch 5 it is possible to trigger external applications, e.g. Microsoft Word & Adobe Photoshop, using the COM interface and control those applications. Will this be possible using the technology available in IMatch 6?
Hi, Ferdinand :) Long time no read!
No, sorry. No COM support or controlling external applications. This is so very rarely used, it makes no sense to hold onto WinWrap Basic just for that.
It is so much easier to use PowerShell or one of the other free programming languages for Windows to use COM or OLE to control applications.
And if you somehow need to transfer data from IMatch, you can access IMWS from a PowerShell script or most other programming languages.
If this really becomes a problem I may think about support for spawning an external process from a script running inside IMatch, e.g. to run an external application or a PowerShell script. We'll see if there is enough demand for such a thing.
Quote from: Mario on January 22, 2017, 12:22:03 PM
No, sorry. No COM support or controlling external applications. This is so very rarely used, it makes no sense to hold onto WinWrap Basic just for that.
This is a blocker for me. That is in addition to a number of workflow scripts that I use and which I no longer have to time to migrate (again).
Quote from: Mario on January 22, 2017, 12:22:03 PM
It is so much easier to use PowerShell or one of the other free programming languages for Windows to use COM or OLE to control applications.
And if you somehow need to transfer data from IMatch, you can access IMWS from a PowerShell script or most other programming languages.
Too much work to redo it all to work like this. Life is too short.
Quote from: Mario on January 22, 2017, 12:22:03 PM
If this really becomes a problem I may think about support for spawning an external process from a script running inside IMatch, e.g. to run an external application or a PowerShell script. We'll see if there is enough demand for such a thing.
I will check in from time to time to see if you choose this option, although it may still not meet my needs. The number of forum users who use the COM interface, and my script that relies on it, is probably small, but I'd have thought that there would be institutional and corporate users who would use it. I bought IMatch 3.4 over 12 years ago for the scripting engine, and most likely when it goes then so .....
Mario, Ferdinand,
I don not understand.
I want simply take some datas from Images in IMatch, like Attributes or metadata, and put them into an external program, like Word.
In WinWrap this is quite easy possible.
Is this not more possible in the future with JavaScript?
Quote from: sinus on January 22, 2017, 01:17:48 PM
Is this not more possible in the future with JavaScript?
You can of course export data from IMatch into external applications.
What Ferdinand is talking about is controlling applications like Word or Photoshop directly from inside IMatch. This will no longer be possible.
I think remember you use(ed) a "Word Contact" script where you used OLE automation from IMatch Basic to control Word directly. This will no longer be possible. But I recal that you abandoned that script and now use Design & Print to create contact sheets and PDF files?
Frankly, I'm very happy to get rid of the OLE/COM automation stuff in IMatch. It was unreliable and unstable and cause a lot of PITA on my part. Ripping out the Basic scripting will deduce complexity in IMatch a lot, and speed certain things up considerably.
Losing the ability to control Office or maybe Photoshop directly from IMatch will affect only very, very few users and that's a price I'm willing to pay. We gain so much from IMatch WebServices and the modern scripting environment.
And it's easy to automate Word from PowerShell scripts anyway. And if a user really needs to automate PS or Word and "use" IMatch data in that process, he can do so easily by writing a PowerShell or Visual Basic and C# script and retrieve data from IMatch using IMWS.
Quote from: Mario on January 22, 2017, 01:31:19 PM
Quote from: sinus on January 22, 2017, 01:17:48 PM
Is this not more possible in the future with JavaScript?
You can of course export data from IMatch into external applications.
What Ferdinand is talking about is controlling applications like Word or Photoshop directly from inside IMatch. This will no longer be possible.
I think remember you use(ed) a "Word Contact" script where you used OLE automation from IMatch Basic to control Word directly. This will no longer be possible. But I recal that you abandoned that script and now use Design & Print to create contact sheets and PDF files?
Ah, I see, phew, you can remember a lot, asthonishing for me. :o
Yep, WordContact is not more a problem for me, you are correct, I use successfully Design & Print (what is a very good tool).
What I have some time, is a script, what does takes some attributres-values and put them into Word.
I have for example 3 files.
In each file are some different numbers, say 100, 122.50 and 222.75.
This is, roughly said, the amount for a bill.
The script takes not these numbers out of the attributes and put them into Word and does create a nice bill (inlcuding adress, date and so on).
This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.
I think, when I see it now correct, this is not more possible with JS.
Quote from: Ferdinand on January 22, 2017, 01:05:39 PM
but I'd have thought that there would be institutional and corporate users who would use it.
Not really, no. I actually expect more institutional/corporate users to start accessing IMatch data now that IMWS is available. I've worked with a customer in Norway who integrated IMatch data and imagery into his Wordpress site using IMWS. The entire project was done in about one day, with only one programmer involved. They now pull IMatch contents into Wordpress using some PHP code.
Another early-bird user from the UK is currently finishing an app based on the free Electron (http://electron.atom.io). Eltron allows you to create 'real' applications using JavaScript. It use the Chrome browser engine and Node.js internally. This means you write the user interface with JavaScript and HTML, but you can also access the file system, databases and of course web services like IMWS.
The end product is a real executable, with an installer and all that.
And it runs on Windows, Mac and Linux!
Very fascinating!
Thanks to IMWS I could create a small application which connects to IMWS, allows me to search the database and to display the resulting files as images in a couple of hours. Could very well evolve to a standalone slide show app or something...
Quote from: sinus on January 22, 2017, 01:42:09 PM
This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.
I think, when I see it now correct, this is not more possible with JS.
Not if your script works by using OLE/COM to "control" Word directly.
But of course you could just export a CSV file with the data and then use this as input for Word. Word has functions to import CSV files to to print bills using the "Serienbrieffunktion". This should even be easier than writing a custom script just to transfer a couple of sums from IMatch.
Exporting a CSV file is already available in IMatch, using the powerful Text export module. You can export IMatch data, metadata and Attributes with many options.
I will provide methods to read/write files for JavaScripts running in IMatch of course. This is a mandatory feature because I will rewrite all Import & Export modules currently using Basic in JavaScript. I'm really looking forward to this, because I can create much better user interfaces in no time with HTML and CSS.
I've just updated the IMatch Anywhere Developer Center (https://www.photools.com/imatch-anywhere/imatch-anywhere-developer-center/) and added a new demo script.
This script shows how to authenticate a user. Once this is done, we can use all IMWS features from scripts.
The new demo has two parts. The second part shows how to use a form to get a user name and password. And it uses a different theme to make the script look like IMatch WebViiewer:
(https://www.photools.com/community/index.php?action=dlattach;topic=6327.0;attach=14536;image)
Quote from: Mario on January 22, 2017, 01:50:34 PM
Quote from: sinus on January 22, 2017, 01:42:09 PM
This script is very good for me, I see in IMatch, how much money an event gave and it is easy to create a bill.
I think, when I see it now correct, this is not more possible with JS.
Not if your script works by using OLE/COM to "control" Word directly.
But of course you could just export a CSV file with the data and then use this as input for Word. Word has functions to import CSV files to to print bills using the "Serienbrieffunktion". This should even be easier than writing a custom script just to transfer a couple of sums from IMatch.
Exporting a CSV file is already available in IMatch, using the powerful Text export module. You can export IMatch data, metadata and Attributes with many options.
I will provide methods to read/write files for JavaScripts running in IMatch of course. This is a mandatory feature because I will rewrite all Import & Export modules currently using Basic in JavaScript. I'm really looking forward to this, because I can create much better user interfaces in no time with HTML and CSS.
Thanks Mario,
This gives me some new courage.
Very appreciated!
To print bills, nicely formatted, using Word is quite easy do to. Many tutorials on the web for that, also for using a CVS file with data (exported from IMatch) as the source for the bills.
Interesting to see what's going to happen with iMatch 6.
I am looking forward to a big new version step.
On the other hand i have a few (quite) long scripts that i frequently use.
Actually the scripting capability was the most important feature when i switched to iMatch.
I cannot believe, only few people use it??!! :o
Visual Basic indeed is veeery old. And i think it's a good idea to introduce new technology.
But, don't say "that's the way it is; use it or leave it".
Come on, not upgrading to IM6 someday is not really an option.
Please make the switch as easy as possible to everyone.
It should definitely be possible to run iMatch 5 and iMatch 6 besides each other.
I am not going to buy another computer, just to do the transition to IM6.
To compromise, it would be enough to not share the settings and databases. But installing and running them parallel should be possible.
Personally, i use the functions below. Will they be available?
Application.SelectFolderDialog()
Application.GetSystemTempFolder()
Application.CreateZIP()
Application.CreateFolder()
Application.GetKeyState()
Set objShell = CreateObject("WScript.Shell")
objShell.Run(cmd)
Set objNetwork = CreateObject("WScript.Network")
objNetwork.MapNetworkDrive
objNetwork.RemoveNetworkDrive
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFile = objFSO.GetFile()
objFile.Copy()
objFile.Delete()
Uff, while scrolling through my scripts (one over 1400 lines) i am definitely not eager to rewrite them. :( :(
Ben
Allowing to run IMatch 6 and IMatch 5.x together on the same system would require:
Maintaining different set of settings, options, storage databases, settings databases.
This will be a lot of work on my part, confusing and potentially dangerous for users if they mess up. It's usually better to don't give users chances to mess things up.
And of course the databases are not compatible. IMatch 6 stores "more stuff" in the database (due to the video support, improved categories, etc.) IMatch 6 automatically migrates IMatch databases when they are first opened. This is a seamless process and users don't even notice (IMatch does that often when new features are introduced). But once this is done, you cannot open the database with an older version of IMatch - instead you will see a warning.
Some of the functions you mention will be available, but others will not.
GetKeyState has no meaning in a browser. There are functions in JavaScript which tell you the key state "in the browser" but the App Panel of course has no access to Windows key states. Not interesting.
There is no support for COM (WScript or whatnot). This is all soo old now...
If you need this, consider writing an external application or a PowerShell script.
You can access the IMatch database contents from external scripts and applications easily using IMWS. This was never possible before, mind!
I will remove Basic Scripting from IMatch as soon as my distribution license for WinWrap Basic runs out. This will be June or July I think. After that point, IMatch will no longer include Basic scripting. Any good riddance I say.
I understand that a few user may be negatively affected by that. But most users won't.
Believe it or not, most users have never written a script. Or even know that this is possible. This was different 10 years ago.
The distribution license for WinWrap costs more per year than my computer, a professional MSDN subscription and all other software and licenses I need for IMatch together. Upgrading to the latest version of WinWrap (with slightly better UI etc.) will cost three times as much - plus higher annual royalties. No way, sorry.
JavaScript gives us powerful tools, super-cool user interfaces. We can write a script once and run it "in" IMatch as well as in any web browser. The script will work with the IMatch database on your local PC but also will work (with IMWS) when your database is running on a PC in your basement or on a server on the other side of the planet.
All technology that will become important in DAM over the next years is based on or linked to web technologies currently available or being developed. IMatch will embrace that thanks to the technologies I have developed for IMatch Anywhere.
Yesterday I've made a few tests with some "A.I." web services which do image analysis.
My little test application (written using JavaScript and running in a browser) sends thumbnails from images in my sample sets to the service . The service responds with info like:
+ Number of persons in the image
+ Gender, age and mood of these persons
+ Objects in the image (boat, car, bicycle, building, street, ...)
+ If the image shows a well-known place or building, I even get the name and address of the building!
+ A description of the image (busy street scene, car race, boat on a river, ...)
+ Suggested keywords for the image
+ Detected License plate numbers
+ Runner numbers (very cool for photographers shooting marathons or similar)
+ If the image shows text of sorts, the extracted text (street names, billboards, ...)
...
Naturally, the system is not always right. Some information may be wrong. People are still better at this than machines. BUT...
...consider this technology included in IMatch. Automatic descriptions, tagging, categorization of files.
You only need to check and correct where it is wrong.
A massive help for people who need to describe or tag many images. Either by starting with DAM or because they shot so many images in a day (sport, wedding, school, event, ...)
And, you don't need to hand over your files to some company and store it in their "cloud". You still keep control over your files.
I fully agree to replace vbasic but converting all the scripts which I have been using, many since IM3, will take time.
We can already use javascript in the app panel. Could you not add the javascript interface library to version 5 so we can
start developing?
And: can we have instructions as to the logistics of programing with javascript... (Where to code (a browser I understand?), how to test....
I have not looked at IMAW so its likely that some of these instructions are there.
IM5 can perform many actions without needing a script. However, if I want to perform a series of steps with just one click I still need
to use a script..
The IMatch Anywhere Developer Center (https://www.photools.com/imatch-anywhere-developer-center/) has links to free tools for developing with HTML and JavaScript. It has links to good on-line tutorials for JavaScript and HTML. This should get you started quickly. There are so many tutorials out there, even videos on YouTube if you prefer that - which is probably one of the reason that JavaScript becomes so huge and is now used from the tiniest little computers to big. big web servers.
The Developer Center also has several example scripts which show the basic steps for using IMWS from JavaScript. I will add more examples over the next months as soon as I finish them.
These scripts work with IMWS now, and will also work "in" IMatch 6 once it is out.
The documentation of all endpoints (methods) provided by IMWS is "built-in", so to speak. You can see it in the IMatch WebViewer when you click on the Gear icon and then select "Discover IMatch WebServices2".
So, i still don't get the whole picture.
Are the following statements correct?
1) Acccessing iMatch functions (=endpoints?) over the web or network is done via IMWS, which is part of iMatch Anywhere.
iMatch 6 will contain the same core functionalities, but doesn't use the same name (IMWS).
2) That means,
I can run a javascript script through my webbrowser -> IMWS
An i can run the same javascript script inside IM6.
3) Besides that, IM6 will contain some extra functions (endpoints), e.g. to access files on my harddrive.
4) COM will not be supported anymore in IM6.
If i want to access "external functions", i need to write a script outside of IM6. -> e.g. controlling word, WScript(), ..
So, e.g. a powershell script can access these "external functions" and i can use the IMWS to access iMatch database functions.
A powershell script cannot access IM6 functions, only through IMWS -> e.g. "get_files_from_filewindow()", or "get_categories_of_current_file()"
That means, whenever i need to access iMatch database functions from the powershell, i need iMatch Anywhere, as well (not only IM6).
5) Calling a subprocess (exec()) from within IM6 is not possible yet.
Ben
Quote from: Mario on January 18, 2017, 04:17:06 PM
I doubt that you can run both IMatch 6 and 5 on the same system, because not only is the IMatch 6 database format 'newer' (to incorporate the changes I make for IMatch 6) but also the versions would need to share settings, plug-ins, configuration files, settings database, .... Way too hard to keep all this synchronized.
I must be missing something simple here, but I really don't understand why it shouldn't/couldn't be possible to have two separate installs of iMatch co-exist on the same computer.
Let's say I have my database and iMatch version 5.7.2 currently on my PC. I'd like to maybe get a later version of iMatch (say, version 6) and play around with it to see if it's something I really want to upgrade to, but I want to keep using my old version 5.7.2 and that database while I'm playing around with deciding about version 6. It really seems like overkill to have to buy/borrow a whole new computer to be able to do that.
Why do those two copies/versions have to share one set of anything or synchronize settings and things between the two versions, i.e., why couldn't the two versions be isolated/independent of each other? Couldn't there be a step during the installation process for the new version that asks whether the user wants to update an existing version or install a new, clean copy of the new version, and then complete the installation accordingly? If the user chooses to update an existing, older version of iMatch, presumably the installer would do what apparently it does now, wiping out the older version and leaving the user with only the newer version of iMatch on their PC. But if the user chooses to do a clean install, it would create a separate, standalone copy of the new version of iMatch (presumably like it does now if the user doesn't have an older version of iMatch on their PC already). Is it really necessary for every version of iMatch to put its settings or whatever in exactly the same place - couldn't it be told to put them in some location specified by the user or at least a location that is specific to the version being installed?
I understand why you wouldn't be able to use both the old and the new version of iMatch on the same copy of the same database, so once you open any particular copy of a database with the newer version there's no way to also open it with the old version. And while it might be nice if both copies could be run at the same time, that could also get pretty confusing and I would understand if maybe that wasn't possible and you had to run either one or the other but not both at any given time. But if I'm willing to maintain separate copies of my database (and presumably separate copies of my image files that are in the database, if necessary), I don't really understand why the new iMatch version has to search and destroy any previous version and can't be allowed to peacefully co-exist with the old version if the user tells it to do so. Probably nothing else I have installed on this PC is quite as complex as iMatch, but I have several games and other programs that appear to have been designed to store whatever settings or other things they need locally within their own separate installation folder structure, and they don't seem to know or care whether I have several separate copies of them installed on the same PC and don't seem to need to share things between the various copies.
(You may note that I used version 5.7.2 in my example above - one of the reasons I'm still back on 5.7.2 and haven't updated to 5.8.2 yet is I generally don't like to risk messing with the old version that is working for me just fine unless/until I've had a chance to play around with the new version to make sure it works OK for my purposes, and having to deal with a second computer to do that tends to drag out the process.)
I understand I won't be able to run V5 and V6 on the same machine.
What about IMAW and V5?
(Since I have no need for IMAW I did not follow its development and I am not aware
how it works together with existing versions. Isn't it just an add-on?)
I only seem to have to install IMAW so that I can develop replacement scripts in advance to V6 coming out.
Quote from: ben on January 23, 2017, 08:53:52 PM
So, i still don't get the whole picture.
Are the following statements correct?
1-3: Correct.
4: Partially correct.
JavaScript has no notion of COM or other proprietary Microsoft technologies.
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.
5. Correct. JavaScript cannot run external processes (thankfully!).
If there is demand I could probably implement this in IMWS and give you an endpoint. Or I implement it as an extension for the App Panel browser (IMatch 5 uses that to make the IMatch scripting API available in the App panel). It's crude and I' happy to get rid of it now that IMWS is there. But I will implement some features like system dialogs (File Browser etc.) that way, and implementing a method than can run launch an external process can be added as well. But that is not COM, no connection can be made to the external app.
That is so rarely used it would be a waste of time. Please understand that not many users use scripting. And of those who do, not many write scripts. And of those who write scripts, not many would ever need something like the Windows Scripting host. Or automate Office applications or Photoshop. I could spend two or three months developing support for that, and then learn that you and Ferdinand are the only users who ever used this...
AFAIK Node.js (https://nodejs.org/en/) can and so can Electron (http://electron.atom.io/). Electron uses Node.js internally. Both "frameworks" allow you to write apps in JavaScript (and to access IMWS and other web services) and give you access to the file system etc. And they work cross-platform.
Quote from: Panther on January 24, 2017, 04:00:28 AM
I must be missing something simple here, but I really don't understand why it shouldn't/couldn't be possible to have two separate installs of iMatch co-exist on the same computer.
1. IMatch 5 and 6 use different database formats. IMatch can automatically upgrade databases (5 to 6) but it cannot downgrade databases. So once your database has been opened with IMatch 6, you cannot longer open it in IMatch 5. This can be solved, of course, by using a copy of your database with IMatch 6.
2. IMatch 6 uses different settings. Again, IMatch can always upgrade settings databases, registry settings etc. But it cannot downgrade them. Your IMatch 5 version may not be able to read the settings anymore.
3. IMatch 6 (may) use different (improved) formats for Batch Processor Presets, Category Schema, Thesaurus, File Window Layouts, Sort Profiles and more.
Of course I can spend time and adding extra code which somehow splits IMatch 6 settings databases and presets from older versions. Install into a different folder, copy and rename the settings database for IMatch 6 and all that. I will think about what would be involved, how much work it will cost me and if it is worth it.
Quote from: ubacher on January 24, 2017, 05:33:33 AM
I understand I won't be able to run V5 and V6 on the same machine.
That's still on the slab. IMatch 6 is a full upgrade and I may decide to duplicate and separate all settings. Then you can run both versions side-by-side (with separate databases!).
But that would require several extra weeks of development so I'm still looking into this.
QuoteWhat about IMAW and V5?
(Since I have no need for IMAW I did not follow its development and I am not aware
how it works together with existing versions. Isn't it just an add-on?)
It's an add-on in the sense that you currently use IMatch to create and manage your database. And when you have IMatch Anywhere you can access the database remotely, from any device and operating system.
QuoteI only seem to have to install IMAW so that I can develop replacement scripts in advance to V6 coming out.
Yes. But you can also just wait until IMatch 6 comes out. No need to rush things.
Or use the IMatch Anywhere TRIAL edition when you can do whatever you want to do in less than 30 days (until the TRIAL edition expires).
Quote from: Mario on January 24, 2017, 09:29:14 AM
Of course I can spend time and adding extra code which somehow splits IMatch 6 settings databases and presets from older versions. Install into a different folder, copy and rename the settings database for IMatch 6 and all that. I will think about what would be involved, how much work it will cost me and if it is worth it.
Things always seem simpler to me than they turn out to be, so I'll certainly understand if this turns out to be too complicated/more trouble than it's worth, but it sure would help people like me to upgrade to new versions with less angst, so I appreciate your willingness to at least look into it. Thanks!
Using the same database with both IMatch 5x and IMatch6x is out of question already. If you want to run both versions side-by-side you need to keep separate databases. I think this is understandable.
I usually "upgrade" the folder holding settings and resources for each major upgrade (which is why it is named C:\ProgramData\photools.com\IMatch5 instead of just "IMatch") and this makes it possible to keep the settings separate. I just need to get logic in place to copy over all the existing settings in the installer or in IMatch 6 itself during the first launch and all that. I did this in the past but of course there is now a lot more stuff around. We'll see.
Note: IMatch 6 is an evolutionary upgrade, not a hard break like the migration from IMatch 3 to 5 in 2014.
IMatch 5 to 6 will be a very smooth transition - except for a small number of users who have written their own scripts.
I depend on users upgrading. My costs are always the same, whether or not you upgrade. And when you don't upgrade, I don't make money and cannot pay for software, licenses, royalties, support and dev time, servers, all the time I spend writing documentations, samples, making videos, ...
Quote from: Mario on January 24, 2017, 04:52:30 PM..... except for a small number of users who have written their own scripts.
I do not write scripts, but certainly use some that others have kindly shared.
Quote from: Mario on January 24, 2017, 09:20:52 AM
Quote from: ben on January 23, 2017, 08:53:52 PM
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
QuoteMaybe 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.
QuoteSo, 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?...
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 :-) )
Quote from: akirot on January 25, 2017, 08:34:04 AM
Mario confirmed the next (scripting) version will not provide write access.
Wrong. I will add write-back features very soon,
Quote from: akirot on January 25, 2017, 08:34:04 AM
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.
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
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.
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:
$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:
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.
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
Quote from: scw2wi on January 29, 2017, 05:41:06 PM
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 (https://www.photools.com/imatch-anywhere/imatch-anywhere-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.
QuoteI 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/ (//http://) 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.
QuoteCopy/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?
QuoteI 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 ;) ;)
QuoteCopy/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.
QuoteI 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?
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.)
QuoteAn 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.
QuoteAn 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.
QuoteFunctions 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... ;)
Quote from: Mario on January 30, 2017, 03:00:10 PM
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...
QuoteIf 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 ;)
QuoteQuoteI 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.
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".
Quote from: axel.hennig on January 30, 2017, 08:23:56 PM
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.
Quote from: Mario on January 31, 2017, 08:32:15 AM
Quote from: axel.hennig on January 30, 2017, 08:23:56 PM
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:
Quote from: Mario on January 31, 2017, 08:32:15 AM
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".
Quote from: Mario on January 31, 2017, 08:32:15 AM
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.
Quotebecause "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.