poll: legacy contributions

[Thomas.Herchenroeder@REDACTED]

A general note: I'm not acquainted with any of the named modules, but
slightly shocked at the thought any of them could be thrown away. Give
it a 10 line README stating its potential and limitation and leave it
for the rest of the world, with a "from this point you're on your own".
Put it in a well-structured archive of modules for others to find, think
about and build upon. They'll know from the timestamp it is old and
unattended.

An example: Since quite a while I'm thinking about the possiblity to
write a firewall system in Erlang. Not that I could really do it, but
I'm thinking about it. And I searched the Web for code that one could
build upon. The topic came up on erlang-questions in 2001, and Luke
Gorrie provided a link to an Erlang "tunnel device" he once had written.
Well, that link is dead, and I dont know if I will ever find this tunnel
device anymore. Maybe the author has lost interest in the code entirely.
But I _am_ interested, even years later.

Never ever throw code away, as long as it is not downright wrong or
superseded by something vastly better. Even if it is badly documented.
It contains brain power other people could use. People learn from other
people's code! Dont throw it away, it might inspire somebody way down
the road.

=Thomas

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of Ulf 
> Wiger (AL/EAB)
> Sent: Monday, August 16, 2004 4:52 PM
> To: 'erlang-questions@REDACTED'
> Subject: poll: legacy contributions
> 
> 
> 
> I thought I'd clean up my list of contributions.
> 
> If any of you are actively using some of the stuff below, 
> please let me know (publicly or privately doesn't matter to me.)
> 
> I will try to summarize my own feelings/plans about each contrib
> below. If you would like me to change my priorities, please send
> me a mail.
> 
> To summarize, I'm most interested in user feedback re.
> 'rdbms', 'builder', 'ccviewer'; I'd like to scrap 'bucket_grid'
> and 'gridfile'; and am curious as to whether anyone is using the
> rest and/or has comments on them.
> 
> 
> User contribs at erlang.org:
> ----------------------------
> bucket_grid-1.0 (http://www.erlang.org/contrib/bucket_grid-1.0.tgz)
>    - Not finished, scalability problems. Should be rethought or 
>      scrapped. I'm thinking of scrapping it.
> 
> ccviewer-1.1 (http://www.erlang.org/contrib/ccviewer-1.1.tgz)
>    - Has been developed further and is in use at Ericsson.
>      I plan to do lots more on this one when time allows.
> 
> dispatcher-1.0 (http://www.erlang.org/contrib/dispatcher-1.0.tgz)
>    - Has been replaced by mdisp-1.0 (see below)
> 
> dynarray-1.0 (http://www.erlang.org/contrib/dynarray-1.0.tgz)
>    - No plans to develop further, but no known problems either.
>      I'm not aware of a faster way to manage large arrays in Erlang.
> 
> filesystem-1.0 (http://www.erlang.org/contrib/filesystem-1.0.tgz)
>    - This type of functionality should be in OTP. I will check to
>      see whether I have newer versions lying around, but am in no
>      great hurry to do so.
> 
> fuz-1.0 (http://www.erlang.org/contrib/fuz-1.0.tgz)
>    - Don't think anyone uses this one. I'd wondered if the improved
>      support for floats shouldn't be used, but why bother?
> 
> gridfile-1.0 (http://www.erlang.org/contrib/gridfile-1.0.tgz)
>    - Same problems as with bucket_grid; same conclusion.
> 
> lines-1.1 (http://www.erlang.org/contrib/lines-1.1.tgz)
>    - Obsoleted by the 'lines' version at Jungerl.
> 
> locker-1.1 (http://www.erlang.org/contrib/locker-1.1.tgz)
>    - Works OK as far as I know. I started working on a version that
>      supports lock hierarchies and "name registration", but the work
>      stalled due to lack of time.
> 
> mdisp-1.0 (http://www.erlang.org/contrib/mdisp-1.0.tgz)
>    - Stable and bug-free afaik. (:
> 
> rdbms-1.3 (http://www.erlang.org/contrib/rdbms-1.3.tgz)
>    - Obsoleted by the Jungerl version.
> 
> view_backup-1.0 (http://www.erlang.org/contrib/view_backup-1.0.tgz)
>    - Don't know if it works with newer versions of Mnesia - assume
>      it does. No plans to develop further; no known problems.
> 
> xmerl-0.17 (http://www.erlang.org/contrib/xmerl-0.17.tgz)
>    - I'm not that involved in the development of xmerl anymore.
> 
> 
> 
> Jungerl components:
> -------------------
> - 'builder' (tool to simplify creation of app files & boot scripts)
>     I like this one, and would like to develop it further, but 
>     will await some user demands. Documentation needs to be greatly
>     improved.
> 
> - 'gen_leader' (behaviour for fault-tolerant servers)
>     Another favourite. Thomas Arts found a bug in the leader election,
>     but I think he's on to a solution. No firm plans to-date.
> 
> - 'lines' (dynamic array of lines - works for other datatypes 
> as well.)
>     I know of one user: Joe. I'm not aware of any problems, and have 
>     no plans to develop it further.
> 
> - 'plain_fsm' (a 'behaviour' for writing upgradeable 'classic' FSMs)
>     Fairly recent invention. I have not thought of anything new to add
>     (except perhaps more documentation.)
> 
> - 'proc_reg' (process registration facility, where any term 
> can be used)
>     Recent invention. Is anyone using it? Needs documentation.
> 
> - 'rdbms' (relational database functionality on top of mnesia)
>     Not 100% standards-compliant on referential integrity. There are 
>     some things that could be done to improve 'rdbms' - foldl & foldr
>     have been suggested; improved support for fragmented tables should
>     be added; ... I'd need to hear more from users.
> 
> Regards,
> Ulf W
>