I am curious. Are you able to see our session text based on the session ID? That was big no in some of the tier-1 places I worked. No employee could see user texts.
> No video files are stored in this repository. The repository simply contains user-submitted links to publicly available video stream URLs, which to the best of our knowledge have been intentionally made publicly by the copyright holders. If any links in these playlists infringe on your rights as a copyright holder, they may be removed by sending a pull request or opening an issue. However, note that we have no control over the destination of the link, and just removing the link from the playlist will not remove its contents from the web. Note that linking does not directly infringe copyright because no copy is made on the site providing the link, and thus this is not a valid reason to send a DMCA notice to GitHub. To remove this content from the web, you should contact the web host that's actually hosting the content (not GitHub, nor the maintainers of this repository).
How come a compilation of pubic streams is eligible for DMCA? Lets wait to get the DMCA notice to be available, it could be either of following
1. Somebody mistakenly/intentionally added a malicious stream.
2. Or DMCA notice is fraud.
In my experience, it always the 2nd one. There are law firms and agencies randomly taking down stuff on internet with their faulty scripts and crawlers.
People will DMCA anything. If some copyright monopolist gets offended by something on the internet it will get DMCA'd out of existence. Whether it's actually fair, just or even legal has no bearing whatsoever. They face no punishment for infringing other people's rights with frivolous claims because you'd have to prove they deliberately acted in bad faith and even that would require people to hire expensive lawyers to do it. In other words, they can leverage the justice system to arbitrarily silence others and then hide behind incompetentence and indiscrimination as an excuse.
Not sure about the claim that async has better Transactionality then REST.
>Transactionality: Each endpoint has either processed a message, done its work (possibly including changing something in a database), and sent a message, or none of it.
The big point with messaging is that you have rollback, and retries. Mats leverages this.
If Stage N in the total process has picked up a message, starts to process it, and then something (temporarily) fails (or the node crashes), then it will roll back whatever DB operations you have done up till then, and roll back that it has picked up the message.
The MQ will now reissue the same message, and it will be picked up again. This time, things work out, a new message is produced, and the entire processing of this stage is committed.
So, either you have received a message, done your DB-stuff, and sent an outgoing message, or you have done none of that.
I do not see you easily do that with REST. Or at least you will have to code quite a bit to get such nice semantics. With messaging and Mats, you get it entirely for free.
But rollback and retries are specific to the systems executing the commands, not the interface that is invoking them. If you have an RPC based transaction (command1, command2, command3) that fills a list with rollback commands and in case of a failure run through the list of rollback commands that does the same thing as putting them in a queue. If you don't have rollbacks in the system (ie stuff was written in the db during the first command) the queue isn't gonna help with that.
I might not have gotten across clearly wrt. how this works.
It is each stage that is transactional. If the stage processing fails (or the node crashes), both the DB transactiona, and the messaging transaction, is rolled back.
It is then retried. ActiveMQ has a default of 1 delivery, and 6 redelivery attempts. If those 7 fails, the message is assumed "poison", and is put on the DLQ.
But this means that a Mats Flow is a series of transactions, each is individually handled. As you probably allude to, you cannot roll back the entire flow - it is just the particular step that is rolled back. Thus, if the message ends up on the DLQ, you have a mid-way process, where the steps in front are already done and committed, while this stage, and any downstream, are not yet done.
The message is however on the DLQ. If the problem was e.g. an temporary database failure, which now is resolved, you can now just reissue the DLQ (move it from the DLQ back to its queue), and the process will continue as if nothing had happened.
I worked on user tracking all my life. You can track user activities, interest etc, much better on an app. This data is valuable for in-house use and to sell it to the highest bidder.
yes yes, there are third party DMPs. Phone companies, offline stores etc. all share data with these DMPs. It is quite disgusting. Particularly shady practices done by FB.
But nothing can defeat first party tracking you get with the app.
