I am looking for a a publicly available and up-to-date roadmap reference resource for DAML and associated developer tools. Does one exist?
The following site is updated approximately once a quarter: https://docs.daml.com/support/roadmap.html
Related
I have a few apps on Play Market and I'd like to publish them on Huawei AppGallery. I care about next dependencies:
com.github.GoogleChrome.custom-tabs-client:customtabs
play-services-ads
firebase-core
Am I right that no one from this list will work? I mean on devices in ban list.
If yes what are workarounds for that dependencies? Or any other/additional restrictions?
For google releated dependencies you have to use huawei provided services or third party SDK.
It's not so much hard to convert them. You can use HMS Core Toolkit, it help you to quickly migrate the app to the HMS to release it in the HUAWEI AppGallery.
Firebase Authentication: Integrate HMS Account Kit, Integrate AGC Auth Service
Fire Base: HMS Push kit.
Firebase Crashlytics: AGC Crash Service.
Firebase A/B Testing: Huawei A/B Testing
play-services-ads: Huawe ADS kit.
As is known, new Huawei devices don't have GMS, like Mate 30 and P40. Huawei has built up an HMS ecosystem to make apps available to improve user experience on these devices. It's recommended that you use GMS if a device supports GMS; otherwise, use HMS (Huawei Mobile Services).
As for dependencies:
play-services-ads: It is recommended that you use HUAWEI Ads Kit.
firebase-core: You can use HMS Core instead.
One more thing, here is the overview of HMS.
You can use productflavors to build two seperate version of your application, one with pure GMS one with pure HMS.
Here is a guide about how you can achieve that:
https://medium.com/huawei-mobile-developers/guide-to-implement-mobile-services-from-different-providers-in-single-codebase-build-variants-b3610fb77fec
And Demo:
https://github.com/Disav0wed/BuildVariantMapsDemo
The ban actually is from US side, Google is just abiding the guidelines.
You can easily deploy your application in AppGallery using Huawei Mobile Services.
Almost all mandatory services are covered as of today, rich community and developer forum support is also available if you stuck up in development or deployment.
In order to deploy your app you can follow up below steps.
Use HMS Toolkit to identify the dependencies.
Once services are identified you can add them in your application.
Codelabs are available to practice as well.
I would recommend to have a single codebase and just switch to GMS or HMS depending on device where your app is downloaded.
Most of the major apps are using same functionality now a days.
Codelab
Developer Forum
Official Documentation of services
I hope this helps you.
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...
I would like to use the FI-LAB platform at http://lab.fi-ware.org. However, I have doubts about which specific generic enablers instances can I use there or the APIs they are exposing.
Thus, where can I find info about instances of FI-WARE GEs deployed on FI-LAB I can experiment with?
A good starting point could be the Developers Portal
http://www.fi-ware.org/fi-ware-developers-portal/
There you will find several core components, most of them available at fi-lab. Follow the "more info" link at each Ge, and then check the "Instances" tab in the general Catalogue to obtain more information of where it is deployed or if it is available at fi-lab instance.
I'm currently working on a no-touch deployment and auto-update mechanism for a Windows application. I've tried Microsoft ClickOnce strategy but it did not work for me as the strategy only suits small-sized apps, and my application hauls at ~500MB.
I'm interested in how the stub based installation and update strategies work for Mozilla Firefox and Google Chrome and also Microsoft's packages including its .NET framework and VS installers. I've come across Google Omaha which hosts the Google product update deployment mechanism, but it is not very conclusive for me.
Can anybody please help me out how the stub-based deployment design works?
P.S. Any open source code for the same would be of a great help. ;-)
I'm not quite exactly sure of what you mean by "stub-based". There's a handful of technologies and tools involved in what I understand you want to accomplish. For the setup packages creation there are: NSIS, Inno Setup and the WiX Toolset, for example. A core technology is MSI. On the other hand, for application updates and the such, there's BITS and also some web stuff involved in updates publishing, like using an ATOM feed, for instance (your referenced Google Omaha might fit into this category).
It's only a bunch of pointers, but I hope it helps.
The Mozilla installer is opensource (as is the NSIS system it uses) so I'd suggest adapting the code found here: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/installer/windows/nsis/
It's a bit complex so you could start with a simpler script and incorporate the bits you want (like finding/downloading updates and UAC evelation).
What is the accepted definition of an API compared to the definition of an SDK? Both seem to be used interchangeably, so I'd imagine that some libraries dubbed APIs are in reality SDKs, and vice versa. Also, is there a reason for this distinction?
Thanks!
An API, or application programming interface, defines a set of classes, functions, and structures to be used by an application to make use of some library or subsystem. For example, both the windows multimedia subsystem, and windows sockets subsystem both have their own API. An API is not a concrete entity, you can't point at a file and say that the file itself is an API. An API is merely a specification for a communications protocol that a program needs to use to make use of a library or subsystem.
An SDK, or software development kit, contains tools, documentation, and needed files, to program against 1 or more APIs. Some SDKs, but by no means all, may contain sample code to demonstrate how an API can be used. 2 examples of an SDK are the Windows Platform SDK and the .NET Framework SDK.
The most likely reason the terms are used interchangeably is because sometimes an SDK only has the tools, documentation, and files for a single API, and both the API and SDK share the same name. An example of this would be the SDK for developing winamp plugins.
API - Application Programming Interface. This is what you write code to.
SDK - Software Development Kit. These are the libraries that you need so you can code. An SDK likely has many different api's contained in it.
None of the answers I've seen so far really capture it clearly and completely.
The two terms are not interchangeable and if someone uses them interchangeably, it indicates a lack of understanding or preciseness.
API - Application Programming Interface. Exposed by a class library. Utilized by an application. When you build an application that uses the library, this is the interface your code uses to connect to or call into the library. In other words the set of rules and conventions applications must follow to use the library. The API includes the classes, their methods, the parameter lists for the methods, and other supporting elements (like enumerations, constants and so on). An API is an abstract artifact: You cannot download an API, or install an API. You can describe an API, and you can use one. The library itself is the concrete realization of the API, the delivery mechanism.
SDK - Software Development Kit. This is a concrete thing. You can download an SDK, install it, store it. An SDK includes:
libraries, which, as you know, expose or provide APIs.
header files (if applicable)
documentation - readme files, help files, release notes, reference documentation, programming guides. Realized as .CHM files, pdf documents, etc.
tools - such as compilers, assemblers, linkers, profilers, debuggers, optmizers, test tools, and more.
sample code and sample apps - showing how to use the API
maybe some other stuff that doesn't fit into one of the above categories
A Concrete Example:
the Java SDK is a downloadable, versioned thing. It delivers libraries, tools (on windows: javac.exe, java.exe, jar.exe, etc), all the help files and API doc, and source code for the libraries.
the API for Java is the set of rules your code must follow to invoke the libraries; these rules are described in the API documentation.
An API is an Application Programming Interface -- its something your program can talk to. An SDK usually includes an API along with documentation for the API. An API is not required to contain documentation. An SDK may include the API Components, but will always include the documentation.
APIs can exist within SDKs but not vice versa. SDKs generally contain a complete specifiction of a framework or environment. For example the Java SDK contains a full specification of the Java language plus tools, external libraries and whatever else the vendor decides to throw in there. The java apis are simply the interface to those specifications.