I updated my pods today and got the latest 6.0.0 version of the SDK. However this seems to be missing the "track" function that was used to interact with the whispers setup on the dashboard. What is the alternative for this?
Whispers support, including the track API, was removed from all three Smooch SDKs in the latest major version releases, since the Whispers feature is currently deprecated and set to be removed from the platform on October 1st. The deprecation was communicated to all Whispers users at the beginning of July 2017.
If you send an email to help#smooch.io describing your use case, there may be the possibility of a workaround, but the newest SDKs were not designed to support Whispers or Whispers-style use cases, so workarounds won't be possible in every case.
Related
I would like to use immutable.js, and see that v4.0.0 is at rc.12. That version string seems to indicate that v4.0.0 is not yet released. Is that because there is a problem with v4.0.0, and we should use 3.8.2, which is three years old? Is there a good fork that publishes v4.0.0 (or higher), so I can depend on it without raising questions about depending upon pre-release packages?
Last autumn a new group of devs have started work to finish 4.0 at the immutable-js-oss repo. It's not clear yet whether (or when) we can merge it back into the main repo (otherwise it will be released as a new package).
There are only a few things left to do for a final 4.0 release, 99% of the issues are already finished. If you are curious, have a look at the issues of the 4.0 milestone. The changes are mostly for compatibility with version 3.x and a few cases for handling very special data (e.g when passing nodejs objects to isolated sub-processes).
Our electron app uses RC12 since 2019, before it was on RC9 for a year. So far none of the 10'000 pilots using it crashed a plane, so I would say it works quite well.
Two days ago the released version of the google maps API was updated to 3.19
Version 3.18 broke some things in our application so we had been explicitly asking for 3.17 until it was deprecated. We updated the application to work with 3.19 and ask for the latest release version, instead of explicitly specifying the version.
Yesterday it went back to 3.18.20, which again broke our application.
We have since updated to explicitly request 3.19, but I'm wondering why the default version is now returning 3.18 instead of the current release version?
Thanks
If you don't specify the version number the version you get will vary according to the documentation on versioning:
You can indicate which version of the API to load within your application by specifying it using the v parameter of the Maps Javascript API bootstrap request. Three options are supported:
The experimental version, specified with v=3.exp.
The release version, specified with v=3
The frozen version, specified with v=3.0
If you do not explicitly specify a version, you will receive the experimental version by default. Google Maps API for Work customers who specify a client ID will receive the release version by default.
If you specify a specific version (i.e. v=3.18), you will get that version while it is available. Once it is retired, you will get the frozen version.
I experienced this same issue, and submitted a bug to Google. See their answer here:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=7694
To reiterate their answer, there were apparently some issues with 3.19, so they reverted their experimental/release/frozen versions. I've chosen to directly use 3.19, as it doesn't seem to introduce any issues for my purposes.
What has been the experience of folks who have already been using OpenDJ and OpenAM? Older versions seem free to use but the new releases don't seem to be free for use. How do they compare to the existing commercial offerings? They look like a better option than using OpenLDAP with CAS but don't look free.
Below you can find answers depending on when this question was asked just for the sake of history.
ANSWER AFTER April 3rd, 2017
With the recent changes made to the business model here you can find the key details you will need to know:
The latest versions of the main products have been firstly renamed, but secondly has been re-versioned to match ForgeRock's Identity Platform views:
OpenAM 14.0.0 -> Access Manager 5.0.0
OpenDJ 4.0.0 -> Directory Services 5.0.0
OpenIDM 5.0.0 -> Identity Management 5.0.0
OpenIG 5.0.0 -> Identity Gateway 5.0.0
The products listed above were all released under a commercial licence, meaning:
The ForgeRock contributed source code (i.e. ForgeRock's intellectual property) is not licensed under an open source licence.
All source code that does not solely belong to ForgeRock (e.g. original source code that belonged to Sun, or source that had open source contributor's work associated with them) will be still available under the CDDL licence and can be obtained as detailed under forgerock.org.
All ForgeRock IP is licensed under a non open source licence.
The products released under the commercial licence can be evaluated for 60 days only.
At the same time of the official release of the new products, community editions have been released for the Open* products:
The community editions are essentially the latest maintenance releases of the last EOL'd versions of the products.
Since these are maintenance releases, they are meant to be firstly more stable, but secondly slightly more secure (only slightly since these versions have not been updated to include the security fixes that have been issued since these versions' original release date).
The community editions can be found under forgerock.github.io
With these new releases every community member will have to make a decision themselves: do they want to go for the latest, but EOL'd stable version of the product, or do they want to try their luck with the latest public, but likely to be less mature software versions (like OpenAM 13.0.0 that was released before the business model change).
Whether community versions will be released/updated by ForgeRock in the upcoming years is currently unknown, no such information has been publicly provided.
Short of an official announcement from ForgeRock, please have a look at this topic in the ForgeRock forum for more details.
To summarize:
The Open* products are still open source and freely available, however they are no longer being publicly developed by ForgeRock. Whether new community versions will be made available is yet unknown, but given the current example, each year the community would get access to an EOL'd version of the product..
ANSWER BEFORE April 3rd, 2017
Here are some facts about the projects and the licensing in general:
Only major releases are made publicly available, which means the source code is available in the format of an SVN tag, whilst the binary that can be downloaded from BackStage will have the binary license on it.
The binary license allows people to test out the product, but it prevents them from using those binaries in production environments without support subscription.
Maintenance versions are not available publicly neither in source nor in binary format.
Each project's trunk (or master) is publicly available, which means that in one shape or form every single bugfix is available, so with some luck it should be possible to cherry-pick important fixes from trunk onto your own special maintenance version.
Each product is relatively simple to build (except maybe the web agents), and as such it shouldn't pose much of a risk to your deployment (ForgeRock does have customers who are building their own artifacts for their deployments, so it is really not a rocket science).
Downloading the artifacts from BackStage only requires some skills on working with agent protected applications, here is an example curl command:
$ curl -O -H "Cookie: fr_sso_sess_prod=AQIC5w..." https://backstage.forgerock.com/downloads/enterprise/openam/openam12/12.0.0/OpenAM-12.0.0.war
Unfortunately it is common that the major releases have some annoying bugs, for those, backporting is relatively simple, since the difference between trunk and the latest major release shouldn't be too big, so you should be able to handle those by manually backporting the fixes. Since major releases happen every ~year or so, you don't have to live with these local changes for too long fortunately.
The projects have active community, and getting help with any kind of issues shouldn't be too difficult (let it be a deployment issue or how to build the projects locally)
Probably I should mention that I'm a ForgeRock employee, so take my comments as you please.
Just to clarify: when you build trunk on your own, you do not have to buy subscription. Only ForgeRock enterprise builds should include the binary license. When building your own stuff, it is you who creates the binaries, hence you can simply decide to leave the binary license out of it.
I'll answer your question in two parts:
First as it compares to existing commercial it's actually a very good solution, as it scales, and it's very feature rich. You can go to the site and read all about the features.
The second part of newer version requiring subscription is somewhat wrong. Mainly because there are subscription downloads from forgerock.com. I assume this are for support service contract reasons that one must purchace. If you want to run the latest version just download the nightly builds forgerock.org, and you will be running the latest version. Lastly I will echo Ludovic's comments about the confusion of free.
[Community] - https://forgerock.org/
[Commercial Support] - https://forgerock.com/
PS. I'm in no way associated with forgerock.
I think you are confusing free as in Free beer and the freedom of open source.
This said OpenAM and OpenDJ are enterprise ready products, mature and used in a large number of mission critical environments including governments, telecom operators, financial institutions, insurances...
What version of the Google Maps API is used if you don't specify a version number? The latest release version perhaps? The documentation about versioning doesn't say.
The documentation does recommend that production apps specify a minor version number. But it also says "all API changes will be backwards-compatible," so is there any reason I should specify a version number if I'm not using any experimental features?
English is not my first language, so I might be reading this part wrong (from the versioning doc you linked)
You can indicate which version of the API to load within your application by specifying it using the v parameter ... The nightly (development) version, specified with v=3 or by omitting the v parameter.
Further down, there's a mention of 3.9 being nightly.
Documentation of Versions
Version 3.9 Reference (Nightly)
So, sounds like leaving out the v (which I do) will load the nightly, version 3.9.
<script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?sensor=false"></script>
About part two of your question: I can think of a very good reason to specify a version:
Consistency, predictability, reliability
You might want to keep the same look-and-feel while working on a update for the latest release of the Maps API. For example, the labels or map controls may move around.
On the other hand, it's good to keep track of the latest versions, too. By lagging too far behind your application might stop working when it becomes unsupported.
I'm sure there are better reasons. I'm not a professional Maps developer.
I've been building extensive Google Maps based applications and according to my experience it's better to specify API version for a long term projects. For example an issue I was facing recently:
The system was built and tested along with v3.6 but Google released an experimental version
Which is loaded by default but from the other hand not recommended for business or professional development.
Therefore to avoid some malfunction that appeared suddenly I had to specify API version:
<script src="http://maps.google.com/maps/api/js?sensor=false&v=3.16" type="text/javascript"></script>
Then after that everything came back to normal. You may quickly consult API version by typing in the browser console google.maps.version.
I hope someone may find it useful.
As new versions of Mercurial are released, we want to somehow enforce that developers, designers, and others are using the approved (or later) version of Mercurial. For example, we are currently on version 1.8.3 I'd like someway of automatically preventing/denying users access our repositories using anything before 1.8.3, and allow any verson after. Can I do this in a hook?
We run our server on Windows and IIS. I thought about writing an IIS extension that returned 500 errors for clients not at the right version, but the client doesn't send any version information in its HTTP requests, just "mercurial/proto 1.0", which I assume means version 1.0 of Mercurial's HTTP protocol.
Is what I want possible? Are there any other ways to solve this?
We want to do this because Mercurial is case-sensitive. We are 100% on case-insensitive Windows. This causes us numerous case-folding collisions. We waste hours on them. Although Mercurial has improved its handling of case, it still has situations where case-folding issues can be introduced. As case-handling improvements are made in new versions, we want someway to enforce our users onto those versions so new problems aren't introduced that we have to spend time fixing.
Do you have strong reasons for wanting to enforce this? Mercurial has internal mechanisms that take care of version features themselves: If you create a repository with 1.8.3 that uses features not yet present in, say, 1.6, then an 1.6 client will refuse to interact with such a repository. In other words, mercurial itself denies access, but not based on version number, but based on actual features. This way, if a new release doesn't break compatibility either way, you can use both versions alongside each other without problems.
Internally, this works because mercurial adds a list of required features to the repository's metainformation, and checks this list before attempting to do anything with it. If the list contains a feature mercurial doesn't know about (yet), it concludes that it cannot meaningfully interact with it and refuses to cooperate.
So IMO the best thing to do would be to simply instate a policy that requires developers to use an up-to-date version, but not add additional technical measures. If someone tries to push with a version that's really too old, then they'll receive an error message, and if they complain, you can simply point them at the official policy.
If you're on Windows, how about deploying the Mercurial installer using Domain policies somehow?