As I think I mentioned, it's great that the people like you on this list
have a passion for delivering cool software.
I may have missed the intent of these two posts (micropayment and messaging
engines), but unfortunately, I don't really consider either of these items
to be application-level items. I consider them infrastructure.
eg it's nice that SmartWorker (as a toolkit) is open source, but opendesk
is closed source. And it's the applications (ironically) in opendesk that
make smart worker worth taking a look at. But it cripples (hope I don't
upset anyone) SmartWorker's marketing to have opendesk closed source
because people prefer downloading apps and then they learn about the
framework it was developed in. Rarely is it the other way around.
People rarely look at toolkits like payment gateways and messaging servers
unless there is an application that fits their needs that they can use
which happens to use these backend components.
So for Adi -- I think the messaging server is great and I am sure it is
cool and works well. And I am sure there are people on this list who will
benefit. But unless your company makes the healthcare system itself open
source, then it's another application that we don't have to make people
interested in using mod_perl from the application side.
Likewise, for micropayments, -- great that there is a micropayment engine.
But unless there are applications to show off using the micropayment
engine, then it's not really helping to bridge the gap except to provide
yet another infrastructural tool.
Will these things come out? Maybe, yes, probably? But there's always been a
lot of infrastructural tools for Apache and mod_perl (eg Apache::Session is
probably one of the most popularly used next to Apache::DBI I suspect) and
yet these components haven't increased the amount of real applications for
people to download and run on mod_perl servers out of the box that they can
modify for their needs.
I don't mean to be disparaging because I hope there is a light at the end
of the tunnel, and I do think applications will eventually come out for
these components, but it's not a given. Sun spends a great deal of money
every year making lots of infrastructural stuff written in Java, but it
doesn't mean there are a lot of open source Java applications either.
The problem is that most company's that spend the time to write an app
based on Java close-source that app. The same thing is true of the mod_perl
world if things like Adi's healthcare system or SmartWorker's OpenDesk
remain closed systems. I know that they consider it their business model to
have to keep these closed source. But it also means less applications on
top of mod_perl to entice the masses to it.
I am sure it will get better, but the economic climate of companies going
under without revenue/profits does unfortunately mean that I am skeptical
that it will happen all at once in this year without a lot of concerted
effort from the mod_perl community to open source their applications that
run on top of mod_perl rather than keeping them all closed source.
At 10:21 PM 4/27/01 -0400, [EMAIL PROTECTED] wrote:
>On Fri, 27 Apr 2001, Jeffrey W. Baker wrote:
>
> >
> >
> > On Sat, 28 Apr 2001, Gunther Birznieks wrote:
> >
> > > Well, you know how I feel. :) But the others don't so...
> > >
> > > I believe the most crucial and missing approach is to put resources into
> > > making ready-made applications that work on mod_perl rather than core
> > > mod_perl itself. This is also a problem on Linux, but that's another
> story.
> > > A quantity of applications for mod_perl or that demonstratively show that
> > > using mod_perl is a benefit (ie fast) is necessary (and I don't mean tech
> > > products like AxKit -- which are great but not what I am talking about)
> >
> > I will be demonstrating a canned micropayment system at O'Reilly in San
> > Diego this year. The reference implementation for the content provider
> > uses mod_perl. I think you are right that most people in non-tech
> > business want a solution that works immediately, rather than a toolbox.
> > The toolbox is already there with Apache, mod_perl, and DBI, now
> > application developers can just step up and deliver.
> >
>
>My company has developed an internal messaging application that is written
>as mod_perl handler / DBI / CGI. It is like the internal messaging
>systems you see at trading sites like etrade, but more featureful... it
>supports sending messages to other users on the system, attaching files,
>and SMTP connectivity. It was designed for use by healthcare parties
>who require a secure environment (we run it behind our SSL server).
>
>We are planning on releasing it as soon as we can fully separate it from
>the rest of our code. Mostly just wanted to let people know in case they
>were in need of something like this and were thinking of developing it
>themselves.
>
>Cheers,
>
>- Adi
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
