mickael

The link is dead but it was a copy of the original post which is here: https://blog.process-one.net/advanced-erlang/

Please, see my other comment, to avoid lengthy repeat, but in short, yes, the goal of the initiative is to grow and yes to be open to other companies that are developing Erlang products at the core of their business.

It is not a join venture between ProcessOne and Quviq, but a broader initiative. However, we need to ensure quality also, so we need a bit of check, but this is taking shape. We will have more to announce very soon it is getting fast :)

All the flaws you mentioned can be solved. We solved them in ejabberd.

The new features and change list is huge: Message archive (Mnesia, MySQL, Postgres, SQLite), configuration checker, Windows installer, RPM and DEB binary packages and over 100 various other changes.

The writer mixes two things: - the app review experience as provided by Apple, which is completely separated from the app itself. - the prompt and incentive added by the developer to guide the user to the right place on iTunes to leave a review.

That said, yes, Apple need to provide an API for integrating app review process into the app.

Who is still using wrist watch ? I have time in front of me on my computer, phone, etc

Why do you say that ?

What about just sorting your emails by increasing size ?

It probably bring a lot of opportunity to build new interesting services.

We have the needed software stack at ProcessOne: http://www.process-one.net/

Contact us if you are interested.

The server knows how to distribute the message to multiple recipient and does that by itself. The client has of course nothing to do. ejabberd does that automatically for presence, but also for Multi-user chat and pubsub.

The original comment was not on transport level multicast, but on application level multicast. This is the one implement in ejabberd patches and thus works over Internet, not only LAN/WAN.

Ah yes, I forgot about this use case :)

That's not true. We have implemented multicast during the Google summer of Code (See for example of the related patch: https://support.process-one.net/browse/EJAB-329). It being test and optimised but works today if you apply the patch. It will be in ejabberd 2.1.

It is implemented in the server for multiple things, including pubsub and multi-user chat.

Note that this type of archictecture could also apply very well to reddit like systems ;)

This is how the XMPP protocol as been designed. It is very powerful and most of all extensible, most likely thanks to the use of XML. If something is not in the protocol, you can add it for your own need.

I would like to write an XMPP client at least for the iPhone, but we are waiting for the native SDK from Apple. For Android, we are waiting for the first devices. But sure it will come.

I think so. For this kind of application, you probably want it tight directly to your list of contacts. Maybe this is the killer application for XMPP based instant messaging ?

I am not talking about silver bullet. I am talking about alternatives. For now people largely think that ther is only one way to do it. The point of my article is to show that there is more than one way to do it and that it might pay off to think about this before hand if you have to make a living of a web-based service.

Hello,

Of course, it is self serving, like 37signals buzz on Ruby was self-serving too. I does not mean that you have to trust me. You can check by yourself and make your own opinion. I really doubt that people will switch to Erlang because I said it is the way to go.

They will do so because they have assessed the technology as an alternative. My goal is only to make Erlang known as an alternative for large scale infrastructure, which is not the case now. Nothing more.