We’ve just released version 1.2.2 of the HTTP File Upload plugin for Openfire. This release includes Ukrainian language support, thanks to Yurii Savchuk (svais) and his son Vladislav Savchuk (Bruhmozavr), as well as a few updated translations for Portuguese, Russian and English.

Grab it from the plugins page in your Openfire Admin Console, or download manually from the HTTP File Upload archive page, here .

1 post - 1 participant

Read full topic

Two months ago, we started using Transifex as a platform that can be easily used by anyone to provide projects for our projects, like Openfire and Spark.

It is great to see that new translations are pouring in! In the last few months, more than 20,000 translated words have been provided by our community!

We’ve enabled the Transifex platform for most of the Openfire plugins (that require translations) today. If you are proficient in a non-English language, please join the translation effort !

1 post - 1 participant

Read full topic

RabbitMQ is one of the world’s most popular open-source message brokers. With its tens of thousands of users (and growing), its lightweight and easy-to-deploy nature makes it a worldwide success across small startups and large enterprises across the globe.

But how do you know if it’s best for your business?

Read on and get the rundown on the reliable messaging software that delivers every time.

So, what exactly is RabbitMQ?

RabbitMQ is an open-source message broker software that implements the Advanced Message Queuing Protocol (AMQP). It is used to facilitate communication between applications or microservices, by allowing them to send and receive messages in a reliable and scalable way.

Simply put, RabbitMQ acts as a mediator between applications that need to exchange messages. It acts as a message queue, where producers can send messages, and then consumers can receive and process them. It ensures that messages are delivered in order, without loss, and provides features such as routing, failover, and message persistence.

RabbitMQ is a highly powerful tool for building complex, scalable, and reliable communication systems between applications.

What is a Message Broker?

A message broker is an intermediary component that sits between applications and helps them communicate with each other.

In short, applications send messages to the broker. The broker then sends the message to the intended receiver. This separates sending and receiving applications, allowing them to scale independently.

The message broker also acts as a buffer between sending and receiving applications. It ensures that messages are delivered in the most timely and efficient manner possible.

In RabbitMQ, messages that are stored in queues and applications can also post and consume messages from them, too. It supports multiple messaging models including point-to-point, publish/subscribe, and request/reply, making it a flexible solution for many use cases.

By using RabbitMQ as a message broker, developers can decouple the components of their system, allowing them to build more resilient, scalable, and resilient applications.

So why should I choose RabbitMQ?

We’ve already touched on this slightly but, there are several reasons why RabbitMQ is a popular choice for implementing message-based systems for your business:

It’s scalable: RabbitMQ can handle large amounts of messages and can be easily scaled up.

It’s flexible: RabbitMQ supports multiple messaging models, including point-to-point, publish/subscribe and request/reply.

It’s reliable: RabbitMQ provides many features to ensure reliable message delivery, including message confirmation, message persistence, and auto-recovery.

Its Interoperability: RabbitMQ implements the AMQP standard, making it interoperable with multiple platforms and languages.

To learn more about RabbitMQ’s impressive problem-solving capabilities, you can delve into our technical deep dive detailing its delivery.

What are the benefits of using RabbitMQ for my business?

RabbitMQ’s popularity because of its range of benefits, including:

Decoupled architecture: RabbitMQ allows applications to communicate with each other through a centralised message queue, decoupling- sending and receiving applications. This allows for a flexible and extensible architecture, in which components can scale independently.

Performance improvement: RabbitMQ can handle large volumes of messages. It also has low latency, which improves overall system performance.

Reliable messaging: RabbitMQ provides many features to ensure reliable messaging, including message confirmation, message retention, and auto-recovery.

Flexible Messaging Model: RabbitMQ supports a variety of messaging models, including point-to-point, publish/subscribe, and request/reply, enabling a flexible and adaptable messaging system response.

Interoperability: RabbitMQ implements the AMQP standard, making it interoperable with multiple platforms and languages.

But don’t just take our word for it.

Erlang’s world- leading RabbitMQ experts have been trusted with implementing RabbitMQ for some of the world’s biggest brands.

You can read more about their experience and the success of RabbitMQ in their business.

When should I start to consider using RabbitMQ?

Wondering when the right time is to start implementing RabbitMQ as your messaging system? If you’re ready for reliable, scalable, and flexible communication between your applications, it might be time to consider.

Here are some common use cases for RabbitMQ:

Decoupled Architecture: RabbitMQ allows you to build a decoupled architecture, in which different components of your system can communicate together- without the need for a tight coupling. This makes your system more flexible, extensible and resilient.

Asynchronous communication: When you need to implement asynchronous communication between applications, RabbitMQ can help. For example, do you have a system that needs to process large amounts of data? RabbitMQ can be used to offload that processing to a separate component, allowing the parent component to continue processing requests, meanwhile, the data is processed in the background.

Microservices: RabbitMQ is well-suited to a microservices architecture, where different components of your system are implemented as separate services. It provides a communication infrastructure, allowing these services to communicate with each other.

Integrating with legacy systems: Do you have legacy systems that need to communicate with each other? RabbitMQ can provide a common messaging infrastructure that allows those systems to exchange messages.

High Availability and Reliability: RabbitMQ provides features such as message persistence, automatic failover, and replication, making it a reliable solution for mission-critical applications.

Multi-Protocol Support: RabbitMQ supports multiple messaging protocols, including AMQP, MQTT, and STOMP, making it a flexible solution for different types of applications.

Ultimately, the choice is yours to use RabbitMQ or any other messaging system, as it all comes down to your specific business needs.

I would like to get started with RabbitMQ!

Whether you are building a small application or a large-scale system, RabbitMQ is a great solution to enable inter-component communication.

We appreciate that you might have further questions, and our team of expert consultants are on hand and ready to talk you through the process. Just head to our contact page .

The post Getting started with RabbitMQ: A beginner’s guide for your business appeared first on Erlang Solutions .

Earlier today, version 10.1.2 release 1 of the Openfire inVerse plugin was released. This plugin allows you to easily deploy the third-party Converse client in Openfire. In this release, the version of the client that is bundled in the plugin is updated to 10.1.2!

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from the plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

A new plugin has been made available for Openfire, our cross-platform real-time collaboration server based on the XMPP protocol. We have named this new plugin the MUC Real-Time Block List plugin.

This plugin can help you moderate your chat rooms, especially when your service is part of a larger network of federated XMPP domains. From experience, the XMPP community has learned that bad actors tend to spam a wide range of public chat rooms on an equally wide range of different domains. Prior to the functionality provided by this plugin, the administrator of each MUC service had to manually adjust permissions, to keep unwanted entities out. With this new plugin, that process is automated.

This plugin can be used to subscribe to a Publish/Subscribe node (as defined in XEP-0060 ), that can live on a remote XMPP domain, but curated by a trusted (group of) administrators). It is expected that this node contains a list of banned entities. When Openfire, through the plugin, is notified that the list has received a new banned entity, it will prevent that entity from joining a chat room in Openfire (if they’re already in, they will be kicked out automatically). Using this mechanism, moderation efforts centralized in one federated Pub/Sub service can be used by any server that uses this plugin.

This plugin is heavily inspired, and aspires to be compatible with, Prosody’s mod_muc_rtbl and the pub/sub services that it uses.

The first version of this plugin is now available on our website and should become available in the list of installable plugins in your instance of Openfire in the next few hours. Please give it a test! We are interested in hearing back from you!

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

I’d like to share some thoughts about Elixir’s with keyword. with is a wonderful tool, but in my experience it is a bit overused.  To use it best, we must understand how it behaves in all cases.  So, let’s briefly cover the basics, starting with pipes in Elixir.

Pipes are a wonderful abstraction

But like all tools, you should think about when it is best used…

Pipes are at their best when you expect your functions to accept and return basic values. But often we don’t have only simple values because we need to deal with error cases . For example:

region 

|> Module.fetch_companies() 

|> Module.fetch_departments() 

|> Enum.map(& &1.employee_count) 

|> calculate_average()

If our fetch_* methods return list values there isn’t a problem. But often we fetch data from an external source, which means we introduce the possibility of an error . Generally in Elixir this means {:ok, _} tuples for success and {:error, _} tuples for failure. Using pipes that might become:

region

|> Module.fetch_companies()

|> case do

  {:ok, companies} -> Module.fetch_departments(companies)

  {:error, _} = error -> error

end

|> case do

  {:ok, departments} ->

    departments

    |> Enum.map(& &1.employee_count)

    |> calculate_average()

  {:error, _} = error -> error

end

Not horrible, but certainly not beautiful. Fortunately, Elixir has with !

`with` is a wonderful abstraction

But like all tools, you should think about when it’s best used…

with is at it’s best when dealing with the happy paths of a set of calls which all return similar things . What do I mean by that? Let’s look at what this code might look like using with ?

with {:ok, companies} <- Module.fetch_companies(region),

     {:ok, departments} <- Module.fetch_departments(companies) do

  departments

  |> Enum.map(& &1.employee_count)

  |> calculate_average()

end

That’s definitely better!

• We separated out the parts of our code which might fail (remember that failure is a sign of a side-effect and in functional programming we want to isolate side-effects).
• The body is only the things that we don’t expect to fail.
• We don’t need to explicitly deal with the {:error, _} cases (in this case with will return any clause values which don’t match the pattern before <-) .

But this is a great example of a happy path where the set of calls all return similar things . But where are some examples of where we might go wrong with with ?

Non-standard failure

What if Module.fetch_companies returns {:error, _} but `Module.fetch_departments` returns just :error ? That means your with is going to return two different error results. If your with is the end of your function call then that complexity is now the caller’s responsibility. You might not think that’s a big deal because we can do this:

else

  :error -> {:error, "Error fetching departments"}

But this breaks to more-or-less important degrees because:

• … once you add an else clause, you need to take care of every non-happy path case (e.g. above we should match the {:error, _} returned by Module.fetch_companies which we didn’t need to explicitly match before)
• … if either function is later refactored to return another pattern (e.g. {:error, _, _} ) – there will be a WithClauseError exception (again, because once you add an else the fallback behavior of non-matching <- patterns doesn’t work)
• … if Module.fetch_departments is later refactored to return {:error, _} – we’ll then have an unused handler
• … if another clause is added which also returns :error the message Error fetching departments probably won’t be the right error
• … if you want to refactor this code later, you need to understand *everything* that the called functions might potentially return, leading to code which is hard to refactor.  If there are just two clauses and we’re just calling simple functions, that’s not as big of a deal.  But with many with clauses which call complex functions, it can become a nightmare

So the first major thing to know when using with is what happens when a clause doesn’t match it’s pattern :

• If else is not specified then the non-matching clause is returned.
• If else is specified then the code for the first matching else pattern is evaluated. If no else pattern matches , a WithClauseError is raised.

As Stratus3D excellently put it: “ with blocks are the only Elixir construct that implicitly uses the same else clauses to handle return values from different expressions. The lack of a one-to-one correspondence between an expression in the head of the with block and the clauses that handle its return values makes it impossible to know when each else clause will be used”. There are a couple of well known solutions to address this.  One is using “tagged tuples”:

with {:fetch_companies, {:ok, companies} <- {:fetch_companies, Module.fetch_companies(region)},

     {:fetch_departments, {:ok, departments} <- {:fetch_departments, Module.fetch_departments(companies)},

  departments

  |> Enum.map(& &1.employee_count)

  |> calculate_average()

else

  {:fetch_companies, {:error, reason}} -> ...

  {:fetch_departments, :error} -> ...

end

Though tagged tuples should be avoided for various reasons:

• They make the code a lot more verbose
• else is now being used, so we need to match all patterns that might occur
• We need to keep the clauses and else in sync when adding/removing/modifying clauses, leaving room for bugs.
• Most importantly: the value in an abstraction like {:ok, _} / {:error, _} tuples is that you can handle things generically without needing to worry about the source

A generally better solution is to create functions which normalize the values matched in the patterns.  This is covered well in a note in the docs for with and I recommend checking it out.  One addition I would make: in the above case you could leave the Module.fetch_companies alone and just surround the Module.fetch_departments with a local fetch_departments to turn the :error into an {:error, reason} .

Non-standard success

We can even get unexpected results when with succeeds! To start let’s look at the parse/1 function from the excellent decimal library. It’s typespec tells us that it can return {Decimal.t(), binary()} or :error . If we want to match a decimal value without extra characters, we could have a with clause like this:

with {:ok, value} <- fetch_value(),

     {decimal, ""} <- Decimal.parse(value) do

  {:ok, decimal}

But if value is given as "1.23 " (with a space at the end), then Decimal.parse/1 will return {#Decimal<1.23>, " "} . Since that doesn’t match our pattern (string with a space vs. an empty string), the body of the with will be skipped. If we don’t have an else then instead of returning a {:ok, _} value, we return {#Decimal<1.23>, " "} .

The solution may seem simple: match on {decimal, _} ! But then we match strings like “1.23a” which is what we were trying to avoid. Again, we’re likely better off defining a local parse_decimal function which returns {:ok, _} or {:error, _} .

There are other, similar, situations:

• {:ok, %{"key" => value}} <- fetch_data(...) – the value inside of the {:ok, _} tuple may not have a "key" key.
• [%{id: value}] <- fetch_data(...) – the list returned may have more or less than one item, or if it does only have one item it may not have the :id key
• value when length(value) > 2 <- fetch_data(...) – the when might not match. There are two cases where this might surprise you:
  • If value is a list, the length of the list being 2 or below will return the list.
  • If value is a string, length isn’t a valid function (you’d probably want byte_size ). Instead of an exception, the guard simply fails and the pattern doesn’t match.

The problem in all of these cases is that the intermediate value from fetch_data will be returned, not what the body of the with would return. This means that our with returns “uneven” results. We can handle these cases in the else , but again, once we introduce else we need to take care of all potential cases.

I might even go to the extent of recommending that you don’t define with clause patterns which are at all deep in their pattern matching unless you are very sure the success case will be able to match the whole pattern .  One example where you might take a risk is when matching %MyStruct{key: value} <- … where you know that a MyStruct value is going to be returned and you know that key is one of the keys defined for the struct. No matter the case, dialyzer is one tool to gain confidence that you will be able to match on the pattern (at least for your own code or libraries which also use dialyzer).

One of the simplest and most standard ways to avoid these issues is to make sure the functions that you are calling return {:ok, variable} or {:error, reason} tuples. Then with can fall through cleanly ( definitely check out Chris Keathley’s discussion of “Avoid else in with blocks” in his post “Good and Bad Elixir” ).

With all that said, I recommend using with statements whenever you can! Just make sure that you think about fallback cases that might happen. Even better: write tests to cover all of your potential cases! If you can strike a balance and use with carefully, your code can be both cleaner and more reliable.

Need help with Elixir?

We’ve helped 100’s of the world’s biggest companies achieve success with Elixir. From digital transformation, developing fit-for-purposes software for your business logic, to proof-of-concepts, right through to staff augmentation development and support. We’re here to make sure your system makes the most of Elixir to be scalable, reliable and easy to maintain. Talk to us to learn more.

Training

Want to improve your Elixir skills? Our world-leading experts are here to help. Learn from the same team who architect, manage and develop some of the biggest in-production systems available. Head to our training page to learn more about our courses and tutorials.

The post Can’t Live `with` It, Can’t Live `with`out It appeared first on Erlang Solutions .

Cobalt 1.3 depends on M-Vault 19.0 or subsequent versions

M-Vault Management Supporties

• M-Vault Bootstrap.   Enables operation in conjunction with M-Vault 19.0 to support headless bootstrap.
• Managing users in M-Vault groups, such as Directory Server Administrators  and Messaging Configuration Read/Write.  This enables Cobalt to control user and operator rights to access M-Vault.
• AD/LDAP passthrough support
  • Allow users (per domain) to support mandatory or partial passthrough
  • Set and validate passthrough entry for user
  • Identify users in passthrough server that might be added to domain

Messaging Management

• Profile Editor for supporting and managing M-Switch Profiler.
  • SIC Coverage UI. Provide full list of SICS, showing which addresses each one goes to.   This enables operator to ensure that all SICs are sensibly handled.
• File Transfer By Email capability is now managed by Cobalt, replacing capability previously in MConsole.
• For Organizations and Military DLs enable control manage capability functions:
  • Max Message Size
  • Max Line Length (for ACP 127 destinations)
  • Charset Restrictions (for ACP 127 destinations)
  • Allows/block attachments
• Option to show for a user which DLs the user is in, and give easy addition to other DLs.  This facilitates managing DL membership.

New Views

• Non-Human Users (Special Users).  Need to support accounts with passwords that are not humans.   For XMPP, Email or both.
• View for end users, rather than administrators.  User can:
  • Change password.
  • See all of own entry and modify  attributes.   The list of modifiable attributes can be configured.
  • See references to entry and email list membership.
• User Groups, to enable management of directory groups (Distinguished Names).

Cobalt Access Control

• New Cobalt roles, that can enable selective control of which users can access directory admin controls, and which users can set OAUTH rights and can add OAUTH Clients.
• Restrict Password set/change rights, so that only selected Cobalt administrators can do this.

Security Enhancements

• When deleting a user, remove the password.   This will make it safe for applications searching whole DIT as you can’t authenticate with a deleted user’s account.
• Security Clearance can be selected for any role or user, based on a configured catalogue.  This supports key M-Switch and Harrier feature to check clearances.

Miscellaneous

• When assigning a new email, search entire DIT for conflicts, not just Cobalt area.   This  helps SASL resilience
• Can add Photos to Routed UAs and Organizations.
• Check References on Delete. Cobalt has a “References” button on user/role form that displays all references of a user/role.  On deleting, references are deleted as well.
• Tool to check references to users in AD, so that when users in AD are deleted, dangling references can be picked up.
• Remove default domain concept
• On deletion of domain in Cobalt, give option to delete all the domain data
• Option to end all  cobalt logged in sessions of an operator, to allow an operator to logout from all browsers with a single action
• There is also an option for an operator with appropriate rights  to end sessions of another Cobalt operator.