This time Lars, I think you are wrong, or perhaps just not hitting what you want to say. You are talking about a login system, but the re-use component IMO is permissions. I admit to being way out of date as to what is in Rails these days, but the seriously full-on permissions system in OpenACS is one of it’s major assets.

Developing a login system is easy. Developing a fully recursive, massively scaleable, audited (etc.) permissions system is hard. Not np-hard, but very time consuming.

And when someone else adds LDAP support to their implementation of Rails permissions/login, do you get to use it for free when you upgrade?

On balance, I totally agree that large scale reuse is an unsolved problem. I have a foot in a number of development camps these days , all of which have their own styles of reuse:

* Perl — CPAN — low (DBI) to high (Catalyst) level reuse — API style and upgrade path defined by each package owner
* OpenACS — OpenACS repositary — low (util procs) to ultra high (bug tracker) level reuse — API style and upgrade path mandated (sort of) by elected group
* Apple Mac development — random projects released under random licenses — low level reuse — API style and upgrade paths usually minimal

Just because totally optimal reuse is an unsolved problem doesn’t mean we should try to stretch higher. Over time I would hope that we learn ways of increasing our reuse and OpenACS is one of the best I have ever come across. The style of reuse there, however, is fairly domain specific – online collaborative apps. Perhaps the problem comes when you try to apply a style of reuse that suits that domain to other domains.

Writing the above bullet points makes me realise that upgrades are closely linked with large scale code reuse. You can’t just upgrade the re-used code without a way to do things like upgrading your database schema and data or versioning your api calls…

Still – I truly hate implementing a new permissions system for every client Perl project just because they want something slightly different. If I had an OpenACS calibre permission/login system to roll out in Perl I would be truly happy!

Perhaps I am the one who hasn’t hit the mark. I get passionate about code reuse – perhaps we need to work on a manifesto along the lines of XP. Extreme Reuse :)

I need to work on these thoughts some more – cross posting to my blog for further contemplation…

Hmm – I don’t have trackback on my blog, but I will magically get it when I upgrade my web framework. Now that’s re-use ;)

I’m pretty happy to not have to deal with the OpenACS permsisions model, though. It never did what I needed it to do for my projects, and it’s impossible to make a UI for it that sane people can figure out to use, because, well, the system model isn’t sane. And it didn’t perform all too well, even if you remembered to only use the magic stored procedure in the SELECT part, not in the WHERE part.

If it does the trick for you, by all means use it.

But I find it much faster to build and easier to test and maintain when I build in just the permissions that I need.

It’s a different way to think about the problem, but given that we’ve tried the other one for 10 years and it isn’t quite working, maybe it’s time to stop thinking execution is the problem, and try something different.

And perhaps that’s really it. Perhaps life is not general in the way we have thought. Perhaps life isn’t best optimised in the same way as a least cost routing algorithm. Most applications are, after all, about augmenting human activites.

People are important.

TCL is unsexy. In fact it’s down right annoying. Possibly even more so than Java. Who hasn’t wasted 30 minutes on a missing space or badly quoted list or on trying to understand Lars’s upvar genius :) The OpenACS framework is powerful, but the learning curve is steep. So many reasons to leave it alone.

But in the ACS/OpenACS community I found people who would (and did) help me grow. I learned more about being a great developer from members of the OpenACS community than from my degree or all the corporate environments I have worked in.

Those same people were why I was confident that OpenACS was a good technology platform to base my business on.

Unfortunately, as time continues to leave the era of the Internet’s birth and Arsdigita behind, the OpenACS community is changing (for possibly unrelated reasons).

More than that, the technology community is changing. Some of the wonder and the fun seems to have gone. I even thought about giving technology away all together. If we can’t make large scale reuse work, are we doomed to repeat the same work over and over again?

What is next? What is going to be great about this decade that we will look back and say "wow, look at how far we have come".

I think part of what you are saying Lars, is that sometimes it’s time to stop flogging the same dead horse. If it’s true that now is that time, then lets not just jump on another horse and do the same thing in a similar direction – what we need is to step back and decide where to go next. Big picture.

I sometimes get frustrated that I don’t have the institutional luxuries of Xerox Parc and I am just a little too young to have accessed the millions of easy dollars of dotcom VC funding. But if I don’t start to dream and then run to achieve those dreams, then I may well wake up in 20 years in a world that is not all I had hoped.

This comment feels a little melodramatic! And how is it related to the original topic? I think that sometimes we fall into exactly the trap that Glass talks about. It is nice to believe that a change in the systems and technologies that we use will take us to where we want to go. In reality though, it is people and vision and relationship that is what we need. Anything else will fall short of what we desire.

Just to return us to the topic to finish off, let’s see what Glass has to say about whether reuse-in-the-large is at all feasable:

<blockquote><i>OK, so reuse-in-the-large is a difficult, if not intractable, problem. Is there any way in which we can increase the odds of making it work?

The answer is "yes." It may be nearly impossible to find components of consequence that can be reused across application domains, but within a domain, the picture improves dramatically

…

Software people speak of "families" of applications and "product lines" and "family-specific architectures." Those are the people who are realistic enough to believe that reuse-in-the-large, if it is ever to succeed, must be done in a collection of programs that attacks the same kinds of problems.</i></blockquote>

And with that I bid you good night!

However, I will add the following data points: I’ve built six web applications that are still being used, and the login system was nearly identical in each one. If you download any of the half-baked PHP web forums or other web applications, login is also pretty close to the same in every system out there.

Although you’ve most likely done a bunch of hairy stuff like authenticating against LDAP, typekey, or passport, I think the majority of Rails newbies just want to get a password protected page up as quickly as possible so that they can get a demo application up and running as quickly as possible.

The login generators available on the Rails wiki were confusing or broken, which probably left a number of people wondering both where to start, and why these things weren’t working, when everything else in Rails seemed so easy.

The simplest solution to the whole login dilemna would be to provide a good HOWTO on building a login system, and make this HOWTO easy to find on the rails wiki. This would satisfy 95% of the people who want to get a simple login system up and running, and the other 5% can continue arguing about it on their blogs. :)

I was browsing the "Agile Web Development in Rails" book at the bookshop the other night, and it looks like there is a section describing a login system. Perhaps the authors of the book could simply make this section available as the free sample chapter. Or else just post somewhere publicly "if you need to build a login system, just see page 34 in the Agile Rails book."