<p><br>
Den 1 okt 2012 17:39 skrev "Loïc Hoguin" <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>>:<br>
><br>
> On 10/01/2012 04:30 PM, Kenneth Lundin wrote:<br>
>><br>
>> I agree with Serge that it is somewhat unfortunate that there are so<br>
>> many initiatives<br>
>> where people write their own implementation of something we already<br>
>> have included in<br>
>> the Erlang/OTP distribution and doing this without even suggesting or<br>
>> asking us if we could<br>
>> incorporate some missing feature or improve the current implementation<br>
>> in various ways.<br>
><br>
><br>
> It happens a lot. People tend to review available options, and if none fits their needs, write something themselves without consulting any of the authors. Sometimes they're right to do so, because the answer they'll get is obvious, and sometimes not.<br>

><br>
> There's a few reasons this happens for this specific case:<br>
><br>
> * HTTP is simple, it's easier to go ahead and experiment on a new project than on an existing one.<br>
> * If the experiment succeeds and the implementation has to differ significantly from other projects, it's not worth backporting since you'll just run into a wall of backward compatibility requirements.<br>
> * OTP has a long release process. Many companies need their fixes to be included quickly to avoid maintaining huge branches for their changes. They generally agree in return to keep track of changes that might happen during the product's development.<br>

I think we are pretty fast with service releases about every 3rd month and updates on the maint branch in git between that.<br></p>
<p>> * Inets is seriously well hidden. I only heard about it after releasing Cowboy. I knew about Yaws/Mochiweb/Misultin but not the inets HTTP server. Many people I talked to didn't seem to know it existed.</p>
<p>I agree on that. I have always thought that the name inets is misleading.</p>
<p>> * Sometimes removing features is an improvement. Inets is big, it's only natural that lightweight alternatives appear. Same happened to Apache, and it's no surprise that Inets is quite similar to Apache from a user point of view.</p>

<p>I agree here too. The http server included in OTP should have been a lightweight one leaving for others to implement a more complete or specialized one.<br>
><br>
> Note that while not everyone uses inets, most servers do use erlang:decode_packet/3 which does most of the job. Cowboy doesn't anymore, because it needed backward incompatible changes to erlang:decode_packet/3. I didn't ask your thoughts, simply because the experiment I did hinted that doing the parsing in full Erlang was a better idea: this change results in improved HiPE optimizations and better reduction management which results in better latency under load.</p>

<p>Interesting, would be good if you could give us more info on this. The http parsing in<br>
decode_packet is there to improve performance. If it is not ( without using HiPE) we should consider removing it!<br>
><br>
><br>
>> In Erlang/OTP we have keep strict compatibility with many of our APIs<br>
>> which is both a strength and sometimes a burden (when we are not happy<br>
>> with the old API) but there are mostly ways around that if there is<br>
>> strong case for a change.<br>
><br>
><br>
> It's a big strength for people looking for stability and a big burden for people looking for reactivity. Can't really blame the second group for finding solutions to their problems.</p>
<p>I am not blaming people for implementing their own solution, it is good to have a lot to choose from. But I still think the stability is very important for the majority of users making systems with a longer life cycle than a year. <br>

Our experience is that we have to be very compatible in order to convince our<br>
users (often big projects) to step up to our latest release.<br>
By this we can also stop supporting older versions.<br>
><br>
><br>
>> We still actively develop inets with its http client and server and I<br>
>> am not sure that<br>
>> all the reasons to develop alternatives still exist.<br>
><br>
><br>
> But like you said the level of support for applications included in OTP vary widely. It is also not clearly indicated which parts are the focus of recent works (there is a small roadmap for the most important stuff but that's about it), nor can it be deduced from reading tickets in a bug tracker or similar collaboration tool.</p>

<p>Yes we plan to improve in this area.</p>
<p>I would say that the level of support is equally high for all applications we regard as important and heavily used by Ericsson and or the external Erlang community.<br>
><br>
> Which brings me to a very important point: please start using a public bug tracker! It doesn't have to be 100% public (as I'm sure you have some issues that are internal only) but it would help a lot if people could see the existing issues instead of stumbling upon the same bugs again and again. It probably also would help with contributions.</p>

<p>We have discussed this as well. <br>
><br>
><br>
>> I think it is of great value to have a relative complete functionality<br>
>> in Erlang/OTP so that<br>
>> the user can implement basic functionality without having to search<br>
>> for separate implementations of, with unknown quality and completeness<br>
>> at least for a beginner.<br>
><br>
><br>
> I would prefer Erlang/OTP to focus on the core features and leave the satellite features to third parties. OTP has an HTTP server but doesn't have proper Unicode support. OTP has OpenGL but doesn't have proper timezones support. These 2 examples missing from OTP are some of many things that are too complex for most people to implement, and that would not benefit from having alternatives.</p>

<p>What is missing when it comes to timezones? Has it been mentioned in another thread?<br>
I think we rely on the OS configuration here.<br>
><br>
> Let's take another example. While taking a quick glance at the modules included in OTP I discovered there is a GD implementation in the percept application. I'm pretty sure most people didn't know it was there, as they usually end up using a NIF. It's quite unexpected that it's in OTP.</p>

<p>It was developed as part of Percept just to have something to use there. We don't regard it complete or general enough to be supported as an app of its own.<br>
><br>
> Finding things in OTP unexpectedly is a quite common occurence, though.<br>
I think most things are documented but the docs could have better search facilities.<br>
><br>
> If the user had a package management application (perhaps working similarly to rebar's deps, = per project/release, no site-wide install by default) along with a package index website, it could quite easily find what he needs. It wouldn't be of unknown quality or completeness, simply because adding a comment and rating system to a package index website is fairly simple to do.</p>

<p>I agree that a package management system would be good. There are initiatives in that direction.<br>
><br>
> Plus, he can make an opinion for himself, instead of just using whatever someone decided for him. You might include a project in OTP that fits your criteria for quality, but it might be crap for someone else. A more democratic system where people choose what they use based on other users' feedback and ratings is not only a lot more powerful but also allows to bring some light on some more obscure projects that are sometimes quite hard to find armed only with Google.<br>

><br>
> It makes sense to have a single choice for big corporate environments, not so much for the rest of the world.<br>
><br>
Striving in that direction.<br>
> -- <br>
> Loďc Hoguin<br>
><br>
> Erlang Cowboy<br>
> Nine Nines<br>
> <a href="http://ninenines.eu">http://ninenines.eu</a></p>
<p>/Kenneth, Erlang/OTP Ericsson<br>
</p>