Re: What is Struts? (was: Re: What is Avalon?)

[Pier Fumagalli]

Jon Stevens <[EMAIL PROTECTED]> wrote:
> 
> FYI, I just *mostly* implemented the J2EE extensions for Turbine's
> Connection pool (the classes now at least implement the interfaces). It took
> me all of about 30 minutes.
> 
> Have fun.

Thank you :) :) :)

Pier

-- 
Pier Fumagalli 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Jon Stevens]

on 2/1/01 5:54 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> * JDBC Connections - javax.sql.DataSource and
> * JMS Connections - javax.jms.QueueConnectionFactory
> or javax.jms.TopicConnectionFactory
> * JavaMail connections - javax.mail.Session
> * URL connections - java.net.URL
> 
> These requirements allow an application to be portable across application
> servers --
> for example, to use whichever JDBC connection pool implementation is provided
> by
> that container.
> 
> Coding an app to the Turbine connection pool's API is certainly feasible, and
> it
> will run in this kind of environment -- but you will not be using the
> container's
> built in facilities, which allow containers to implement things like
> distributed
> transaction support, integrated authentication checking, and everything else
> that is
> in the J2EE platform requirements.

FYI, I just *mostly* implemented the J2EE extensions for Turbine's
Connection pool (the classes now at least implement the interfaces). It took
me all of about 30 minutes.

Have fun.

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
 | 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Back to Avalon...

[Jon Stevens]

on 2/2/01 12:27 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> At 11:10  2/2/01 -0800, Jon Stevens wrote:
>> Ok, I'm seeing other people discuss this without any sort of final decision
>> here, so I think we need to get back on topic. So far, top level package
>> names are expressly reserved for top level projects.
> 
> Well not every one seems to obey it. Examples include catalina (3 top level
> names - catalina, naming, jasper), James (mailet, james). I am sure I could
> for more examples if I looked ;)

I personally obey it and as someone at the PMC level, then I see my job as
being to encourage you and others to obey it as well. Two wrongs don't make
a right. I personally think that the namespace for Tomcat should really be:

org.apache.tomcat
org.apache.tomcat.naming
org.apache.tomcat.jasper (at least until it is split out of the Servlet API)

Catalina itself should live within the Tomcat namespace since it is simply a
revolution that has already been voted to become Tomcat.

For a perfect example of this, I created Anakia which is used as the basis
to power our website. I placed Anakia within org.apache.velocity.anakia and
created a small documentation page for Anakia within the Velocity project.

There are several things within Turbine that could be spun out as separate
projects as well such as Torque, DB connection pool, Intake, etc...however,
I haven't found the need so far to do that...(although, it is starting to
become more clear there is a need for that)...

>> I would be +1 for something like this:
>> 
>> org.apache.avalon
>> org.apache.avalon.phoenix
>> org.apache.avalon.cornerstone
> 
> I would be -1 for it ;) The reason is we are just moving away from this.
> The reason is that the base framework is used by phoenix rather than
> phoenix being a part of avalon. I would put it in the same acceptability as
> mandating "org.apache.turbine.jetspeed" as Jetspeed uses Turbine.

Then you should be suggesting another top level project be created instead
of creating a pseudo project that is half within Avalon and half within the
top level namespace.

Just like there is for Jetspeed.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Back to Avalon...

[Charles Benett]

Jon Stevens wrote:
> 
> on the JAMES list: 2/2/01 3:07 AM, "Charles Benett"
> <[EMAIL PROTECTED]> wrote:
> 
> > (FYI - Avalon is splitting, probably, into 3 packages: org.apache.avalon
> > - the design framework and utilities, org.apache.phoenix - the server
> > kernel based on avalon designs, and org.apache.cornerstone - commonly
> > required services and blocks implementing them for use in phoenix
> > servers. I see James using all three packages and their subpackages)

(Which is just a description of the Avalon-3.1a1 release, which other
James users/devs need)

> Ok, I'm seeing other people discuss this without any sort of final decision
> here, so I think we need to get back on topic. So far, top level package
> names are expressly reserved for top level projects.
> 
> I would be +1 for something like this:
> 
> org.apache.avalon
> org.apache.avalon.phoenix
> org.apache.avalon.cornerstone
> 

But:
1) The org.apache.avalon.* code has far wider applicability than its use
in phoenix, so at some point avalon should become two or three separate
top-level projects.
2) Changing the package names later (ie when the projects split) would
lead to unhappy users of the code, and may put off new adopters
3) Not changing the package names now leaves us with very deep package
hierarchies, which can confuse new adopters
So: lets move to the new packages now.

Charles

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

On 2/3/2001 at 8:13 AM Peter Donald wrote:
> We can't force projects - especially new ones - to reuse existing
codebases but overtime we should encourage it.

Thanks for saying this better than I did, Peter. +1.

I'd like to be a good Apache scientist some day, but sometimes it's
hard to understand these things secondhand. 

-T.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Back to Avalon...

[Peter Donald]

At 11:10  2/2/01 -0800, Jon Stevens wrote:
>Ok, I'm seeing other people discuss this without any sort of final decision
>here, so I think we need to get back on topic. So far, top level package
>names are expressly reserved for top level projects.

Well not every one seems to obey it. Examples include catalina (3 top level
names - catalina, naming, jasper), James (mailet, james). I am sure I could
for more examples if I looked ;)

>I would be +1 for something like this:
>
>org.apache.avalon
>org.apache.avalon.phoenix
>org.apache.avalon.cornerstone

I would be -1 for it ;) The reason is we are just moving away from this.
The reason is that the base framework is used by phoenix rather than
phoenix being a part of avalon. I would put it in the same acceptability as
mandating "org.apache.turbine.jetspeed" as Jetspeed uses Turbine.

Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 08:33  2/2/01 -0500, Sam Ruby wrote:
>Now it irritates me that one has to have separate database pools for
>Struts, JetSpeed, and Cocoon.  I don't honestly care how beautiful the
>internal APIs are, or compatible with some corporate strategy the solution
>is, I just want to be able to share database connections.  Is that so bad?

It's painful when the only way interaction between groups occurs is when it
is forced by some group like SUn who introduces a standard extention for it.

>Unfortunately, the last itch requires more than individual effort - it
>requires teamwork.  Making the core functionality pluggable, or wrappering
>it with a J2EE facade or a Avalon facade, or even making sure that Struts
>remains a single jar are mere technical problems.  It is the recognition
>that out there in the chaos that is open source, somebody will want to
>include more than one subproject in their workspace that I desire more
>people to see.

agreed.

>One other thing to ponder.  Sourceforge is a random collection of open
>source projects, each doing their own thing.  Some successful.  Some
>abandoned.  In Jakarta, some of us have worked hard to produce something
>different - a community centered around the building of related software.
>Perhaps we are deluding ourselves.  You tell me.

Unfortunately it has a little to do with the rate at which jakarta aquires
projects and the rate at which new standard extentions are created to fill
the "holes". We can't force projects - especially new ones - to reuse
existing codebases but overtime we should encourage it.

Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 07:41  2/2/01 -0500, Ted Husted wrote:
>When considering the merits of a product, it is important to consider
>the human factor of both our users and developers. It's no secret the
>teams working on competiting solutions often "hate each other". Maybe
>that's a good thing. It may not be as efficient, but given the human
>factor, duplicating resources and fostering competition is usually more
>* effective * than "benevolent" cooperation. 

I dislike the implications of this. You advocate reinventing a wheel
because you can - and better - you get to spit in someone else face. These
things - desirable or not - do not belong inside Apache. Yes - competition
is good however not the type you advocate. Look at the cocoon vs turbine
competition. I remember a time when both groups thought the other didn't
know what they were doing. It wasn't till later that some Cocoon2 peeps
crossed over to the other side and saw Turbine was good (ot sure if vice
versa is true). 

>We need more than just science. We need scientists. 

Only if they are good Apache scientists - no need to get us more scientists
who don't want to follow the Apache way. There is plenty of other
organisations that can host them.


Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Peter Donald]

At 10:52  2/2/01 +0100, Ceki Gülcü wrote:
>
>Sorry. I inadvertently pressed Ctrl-e which made Eudora forward my
incomplete note. Here is the complete note.
>
>At 19:19 01.02.2001 -0800, you wrote:
>>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>>
>>> [ Running, ducking, and grinning ;-) ]
>>> 
>>> - Sam Ruby
>>
>>
>>
>>Do not try to resist.
>>We must follow Sun standards.
>>Resistance is futile.
>>J2EE is the only solution.
>>We are Borg. 
>>JSP, XML and EJB is the only way.
>>We will assimilate you.
>>
>>
>
>
>There is a lot of insight in this . Sun is doing a great job at
convincing people to use their technology. This is truly a Herculean task
and imho constitutes a major achievement for Sun.
>
>We should perhaps learn from their JCP model. This is what I *think* they do:
>
>1)  Identify a problem area.
>2)  Find a number of experts willing to contribute. 
>3)  Designate a leader.
>
>The ordering of (2) and (3) can be inverted.
>
>4a) Define requirements. 
>4b) Consolidate those requirements into a document.
>5a) Define a spec based on the requirements. 
>5b) Consolidate the spec into a document. 
>5c) Publicize the spec.
>
>Step 5 is iterative.
>
>6a) Quitely write code that implements the spec. Do not release/publicize
this code to avoid the burden of maintenance.
>6b) When ready, release alpha code to select users.
>6c) When ready, release beta to a larger set of users.
> 
>7)  Take the world by storm when the API+code is ready.
>
>Sun also has an uber-plan consisting of a new release of the JDK. A new
JDK will mass distribute the new APIs so that there will be no point or
very hard to resist any new API. Steps 1 through 6 ensure that the new API
is not botched. (No one will use a manifestly botched API.)
>
>The challenge in this model is to find a competent and respected leader as
well as experts willing to contribute. 

I think you overestimate the good naturedness of Sun. Like any other
buisness they are in it for the money. The purpose of the API is generally
not to be the best/good at what it does - that is an ancilliary concern -
the purpose is to establish a standard so that buisnesses can adopt java
and understand which technologies are going to be supported and thus have
easy training/management of such things.

Many of these specs are reactionary to equivelent MS "standards".
Fortunately it now looks like Sun is starting to also work with rather than
against other standardisation groups (ie see JDO and ODMG spec and other
interaction with the OMG etc).

Sun also does not accept things that would threaten it's vision (ie
lightweight clients powered by super computers). Consider the case of
select() style functionality - why has not that been added. It's not
because it isn't portable, nor is it because it is technically hard or a
design challenge. I put it to you that the sole reason is because it would
mean that low end servers with a small number of CPUs could actually start
to compete with the suns network OS hardware which would be a bad thing for
them. Yet not having this functionality has proved considerably challenging
to anyone running java as server and in native threads mode. I suspect this
will change with Merlin release as more people were allowed to have an
opinion.


Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Back to Avalon...

[Jon Stevens]

on the JAMES list: 2/2/01 3:07 AM, "Charles Benett"
<[EMAIL PROTECTED]> wrote:

> (FYI - Avalon is splitting, probably, into 3 packages: org.apache.avalon
> - the design framework and utilities, org.apache.phoenix - the server
> kernel based on avalon designs, and org.apache.cornerstone - commonly
> required services and blocks implementing them for use in phoenix
> servers. I see James using all three packages and their subpackages)



Ok, I'm seeing other people discuss this without any sort of final decision
here, so I think we need to get back on topic. So far, top level package
names are expressly reserved for top level projects.

I would be +1 for something like this:

org.apache.avalon
org.apache.avalon.phoenix
org.apache.avalon.cornerstone

thanks,

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Olympics (was: Re: What is Struts? (was: Re: What is Avalon?))

[Jon Stevens]

on 2/2/01 1:34 AM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

> Sun is doing a great job at convincing people to use their technology. This is
> truly a Herculean task and imho constitutes a major achievement for Sun.

Nope. Sun is doing a great job emulating M$. JSP is only better than ASP
simply because it is Java, not because it is a better design. Is JSP better
than .NET? I don't know yet, but M$ usually doesn't make the same mistakes
with regards to technology decisions twice. Anyone remember that M$ was
"missing" on the Internet for so long and when Bill woke up, he assimilated
as much Internet related stuff as he could.


Spelling it out:


What I would love to see, more than anything in this world at this point
(besides whirrled peas), is Microsoft to announce that it is going to Open
Source its entire .Net platform on May 28th...exactly two weeks before
JavaOne.

History tells us that JavaOne is the only time of the year that anyone in
Open Source land can get Sun to do something positive for the overall
communities and this usually happens as a result of some weird Sun internal
firestorm pressure to do things quickly right before JavaOne.

We spent about a year trying to convince Sun to Open Source Tomcat. Suddenly
a few weeks before JavaOne the firestorm happened and the next thing I know
is that I'm on stage with Brian, Pier, Stefano and Patricia at her JavaOne
keynote making the big announcement.

Timeline:

 1998: Jakarta/Tomcat
 1999: Apache/XML
 2000: Open Source Java (tm)?

So, what should we hope for this year from Sun? So far, I expect pretty
little since there hasn't been any real new acronyms popping up like gold
(probably due to the current .bomb mess).

However, seeing M$ come up with something really good would be great
pressure for Sun to emulate something else from M$.

2 weeks would just be a nice world speed record for the gold.

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Listing your e-mail address

[Ceki Gülcü]

Hi,

Since there seemed to be wide support, all e-mails are now listed in "x at y.z" form. 
If you are unhappy about this them give me a shout and I will change the e-mail 
address relative to your entry. Ceki

At 09:27 02.02.2001 -0800, you wrote:
>Ceki Gülcü wrote:
>
>> Hello,
>>
>> Daniel Savarese suggested that e-mail addresses on the "Who we are" page should not 
>be listed directly as mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at 
>bar.com".
>>
>> This is will make it harder for spam robots to collect our e-mail addresses. For an 
>example of how this will look, see Daniel Savarese's entry.
>>
>> I intend to generalize this way of listing e-mail for all entries. If you think 
>this is a bad idea, then please let me know. Cheers, Ceki
>>
>
>+1
>
>Craig
>
>
>>
>> ps: The URL for the "who we are page" is 
>http://jakarta.apache.org/site/whoweare.html.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]


Ceki Gülcü   e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5  [EMAIL PROTECTED]
CH-1005 Lausanne  
SwitzerlandTel: ++41 21 351 23 15


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Listing your e-mail address

[Delagrange, Morgan]

Title: RE: Listing your e-mail address





+1


Ceki, is there a call for names/email addresses implied here?  I know that mine isn't on the site, and it seems that you're contemplating making us all famous.  :) :) :)

- Morgan



> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 02, 2001 11:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Listing your e-mail address
> 
> 
> Ceki Gülcü wrote:
> 
> > Hello,
> >
> > Daniel Savarese suggested that e-mail addresses on the "Who 
> we are" page should not be listed directly as 
> href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at bar.com".
> >
> > This is will make it harder for spam robots to collect our 
> e-mail addresses. For an example of how this will look, see 
> Daniel Savarese's entry.
> >
> > I intend to generalize this way of listing e-mail for all 
> entries. If you think this is a bad idea, then please let me 
> know. Cheers, Ceki
> >
> 
> +1
> 
> Craig
> 
> 
> >
> > ps: The URL for the "who we are page" is 
> http://jakarta.apache.org/site/whoweare.html.
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Re: Listing your e-mail address

[Craig R. McClanahan]

Ceki Gülcü wrote:

> Hello,
>
> Daniel Savarese suggested that e-mail addresses on the "Who we are" page should not 
>be listed directly as mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at 
>bar.com".
>
> This is will make it harder for spam robots to collect our e-mail addresses. For an 
>example of how this will look, see Daniel Savarese's entry.
>
> I intend to generalize this way of listing e-mail for all entries. If you think this 
>is a bad idea, then please let me know. Cheers, Ceki
>

+1

Craig


>
> ps: The URL for the "who we are page" is 
>http://jakarta.apache.org/site/whoweare.html.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[cmanolache]

My 2c:

Instead of talking it would be easier to create another repository, say 
"jakarta-utils" ( or just use jakarta-tool since it's there :-), and start 
organizing the reusable code in avalon, turbine, tomcat, etc.

I don't see any problem with having 2 connection pools - as long as both
are self-contained and easy to pick and use. 

The problem is when in order to get a connection pool you have to take the
whole package, and it depend on other 10 components. 

It's a huge difference between a "CPAN" where you can get the component
you need ( Graph.pm, GDU.pm ) and what I see here - a XXX where you
have to download the whole archive to use one component. 

IMHO the problem is in the way the code is organized - low level
components should be in a common repository ( jakarta-util ), each with
it's own directory and minimal external dependencies. ( plus explicit list
of deps ). If we'll have 5 connection pools, each having specific
advantages - that's great, having to choose is not bad. All commiters 
to individual projects should be automatically commiters to util, 
and we should periodically scan the projects for "general-purpose" code 
and move it to jakarta-util. 

( probably we'll get 5 StringManagers - but  at least they'll be next to
each other )

-- 
Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

>On 2/2/2001 at 8:33 AM Sam Ruby wrote:
In Jakarta, some of us have worked hard to produce something different
- a community centered around the building of related software. Perhaps
we are deluding ourselves.  You tell me.

I would venture that if the goal of each Jakarta product were to be the
defacto (or actual) reference implementation for it's breed, then the
relations will follow.  Besides meritocracy, another important Apache
principle is "correct first". If we pursue that, the rest will follow.

A good role for the Jakarta PMC is to stay in touch with what the
various product teams are planning, and try to suggest a link to
another product when an idea is gestating (repeat, gestating). Another
good role is to point-out to a team where there is signicant component
that could be turned into a product in its own right. 

On the table now is a Jakarta connection pool product. Another
candidate might be the Jetspeed portlet. 

But to be useful to the other products, these components must also be
exposed at the product level, and have their own set of committers,
release plans, and the rest of it. The Ant model is a good one: the
developers of one Jakarta product become the users of another.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Sam Ruby]

Ted Husted wrote:
>
> > The desire to work together is core to my thesis that
> > there is a Jakarta community here.
>
> There often seems to be an assumption that our resources,
> or community, is limited. There are a great number of
> Java developers in the world, and our numbers grow every
> day. A project like Struts, with a clear internal focus
> on J2EE compatability can easily attract developers that
> would not otherwise contribute. I happen to be one.
>
> Are we building a cathedral, or a bazaar?

Hmm.  I'm not sure how you got that from my statement, but lets go with
that for a moment.

Many have noticed that I personally enjoy the diversity that exists in
scripting languages, template frameworks, and the like.  To me, that's not
the issue.

Open source is about scratching itches.

It irritated me that PHP is somewhat under the Apache umbrella, and so is
Tomcat, but one couldn't make them work together.

It irritated me that Tomcat originally prereqed Sun's parser and many
Apache projects prereqed Xerces, making them difficult to run together.
Some progress has been made, but some projects (like xml-batik and
xml-axis) haven't quite gotten the message.

Now it irritates me that one has to have separate database pools for
Struts, JetSpeed, and Cocoon.  I don't honestly care how beautiful the
internal APIs are, or compatible with some corporate strategy the solution
is, I just want to be able to share database connections.  Is that so bad?

Unfortunately, the last itch requires more than individual effort - it
requires teamwork.  Making the core functionality pluggable, or wrappering
it with a J2EE facade or a Avalon facade, or even making sure that Struts
remains a single jar are mere technical problems.  It is the recognition
that out there in the chaos that is open source, somebody will want to
include more than one subproject in their workspace that I desire more
people to see.

One other thing to ponder.  Sourceforge is a random collection of open
source projects, each doing their own thing.  Some successful.  Some
abandoned.  In Jakarta, some of us have worked hard to produce something
different - a community centered around the building of related software.
Perhaps we are deluding ourselves.  You tell me.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

Do not try to resist.
We must use Turbine.
JSP is futile.
Turbine is the only solution.
We are Borg. 
Only Turbine knows the  way.
We will assimilate you.



"Choose your enemies wisely ... for you will become them."


> Needless to say, I think that I'm going to start doing my own
comparisons and placing them up for people to comment. 

Choice is good. Let's have more choice. 


> you are arguing that it code re-use is a bad thing and we all know
that isn't true.

Creating better products with less effort is good. 

When code reuse contributes to that goal, then code reuse is a good
thing. 

But code reuse is neither the goal nor a panacea. 

If this is a meritocracy, and decision-making is being push down, then
a subproject is entitled, even obligated, to decide for itself when it
is better to rewrite than reuse. 

Of course, anyone who disagrees can always make a proposal, provide a
working alternative, and let the subproject Committers decide what's
best for the product and its users. At least if this is really a
meritocracy.

It's also important to remember that Java is a components-based
architecture. It would be reasonable for a product to provide a simple,
easy-to-configure solution as part of the release package, and then
also document how to hook into more full-featured solutions, including
a special-purpose Jakarta product, like a datasource pool. Choice is
good. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ted Husted]

> The desire to work together is core to my thesis that there is a
Jakarta community here.

There often seems to be an assumption that our resources, or community,
is limited. There are a great number of Java developers in the world,
and our numbers grow every day. A project like Struts, with a clear
internal focus on J2EE compatability can easily attract developers that
would not otherwise contribute. I happen to be one. 

When considering the merits of a product, it is important to consider
the human factor of both our users and developers. It's no secret the
teams working on competiting solutions often "hate each other". Maybe
that's a good thing. It may not be as efficient, but given the human
factor, duplicating resources and fostering competition is usually more
* effective * than "benevolent" cooperation. 

We need more than just science. We need scientists. 

Are we developers looking for projects, or products looking for
developers?

Are we building a cathedral, or a bazaar?


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML Push

[Tod Thomas]

Thanks!

Sam Ruby wrote:

> Tod Thomas wrote:
> >
> > Could anyone point me in the direction of some documentation
> > that describes implementation of xml push technology ?
>
> Here's a few:
>
> http://msdn.microsoft.com/msdnmag/issues/01/01/xml/xml.asp
> http://msdn.microsoft.com/net/ecma/main.asp?Class=XmlReader
> http://www.extreme.indiana.edu/soap/
>
> The first one is a good overview.  The second is details on the Microsoft
> approach.  The final one is an open source implementation in Java (you'll
> have to page down past the SOAP info to find it).
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What is Avalon?

[Ignacio J. Ortega]

> reaches almost 5'11"... And 4 inches are _something_ :)
> 
> Pier (thinking: Tomcat is higher than anything else, I'm 6'0")

Which tomcat ? i'm about 6'7" :-)


Saludos ,
Ignacio J. Ortega

PS: Sorry for waste of bandwidth :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Listing your e-mail address

[Ceki Gülcü]

At 20:47 02.02.2001 +1100, you wrote:
>At 09:22  2/2/01 +0100, Ceki Gülcü wrote:
>>
>>Hello,
>>
>>Daniel Savarese suggested that e-mail addresses on the "Who we are" page
>should not be listed directly as href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at bar.com".  
>
>good idea. Oh and just in case no one saids it - You rock.

You are not bad yourself. :-) Ceki



Ceki Gülcü   e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5  [EMAIL PROTECTED]
CH-1005 Lausanne  
SwitzerlandTel: ++41 21 351 23 15


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ceki Gülcü]

Sorry. I inadvertently pressed Ctrl-e which made Eudora forward my incomplete note. 
Here is the complete note.

At 19:19 01.02.2001 -0800, you wrote:
>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
>> [ Running, ducking, and grinning ;-) ]
>> 
>> - Sam Ruby
>
>
>
>Do not try to resist.
>We must follow Sun standards.
>Resistance is futile.
>J2EE is the only solution.
>We are Borg. 
>JSP, XML and EJB is the only way.
>We will assimilate you.
>
>


There is a lot of insight in this . Sun is doing a great job at convincing 
people to use their technology. This is truly a Herculean task and imho constitutes a 
major achievement for Sun.

We should perhaps learn from their JCP model. This is what I *think* they do:

1)  Identify a problem area.
2)  Find a number of experts willing to contribute. 
3)  Designate a leader.

The ordering of (2) and (3) can be inverted.

4a) Define requirements. 
4b) Consolidate those requirements into a document.
5a) Define a spec based on the requirements. 
5b) Consolidate the spec into a document. 
5c) Publicize the spec.

Step 5 is iterative.

6a) Quitely write code that implements the spec. Do not release/publicize this code to 
avoid the burden of maintenance.
6b) When ready, release alpha code to select users.
6c) When ready, release beta to a larger set of users.
 
7)  Take the world by storm when the API+code is ready.

Sun also has an uber-plan consisting of a new release of the JDK. A new JDK will mass 
distribute the new APIs so that there will be no point or very hard to resist any new 
API. Steps 1 through 6 ensure that the new API is not botched. (No one will use a 
manifestly botched API.)

The challenge in this model is to find a competent and respected leader as well as 
experts willing to contribute. 

et voila, Ceki


Ceki Gülcü   e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5  [EMAIL PROTECTED]
CH-1005 Lausanne  
SwitzerlandTel: ++41 21 351 23 15


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Listing your e-mail address

[Peter Donald]

At 09:22  2/2/01 +0100, Ceki Gülcü wrote:
>
>Hello,
>
>Daniel Savarese suggested that e-mail addresses on the "Who we are" page
should not be listed directly as mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at bar.com".  

good idea. Oh and just in case no one saids it - You rock.


Cheers,

Pete

*--*
| "Computers are useless. They can only give you   |
|answers." - Pablo Picasso |
*--*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Struts? (was: Re: What is Avalon?)

[Ceki Gülcü]

At 19:19 01.02.2001 -0800, Jon Stevens wrote:
>on 2/1/01 6:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
>
>
>Do not try to resist.
>We must follow Sun standards.
>Resistance is futile.
>J2EE is the only solution.
>We are Borg. 
>JSP, XML and EJB is the only way.
>We will assimilate you.
>
>

There is a lot of insight in this . Sun is doing a great job at convincing 
people to use their technology. This is truly a Herculean task and imho constitutes a 
major achievement for Sun.

We should perhaps learn from their JCP model. This is what I *think* they do:

1) Identify a problem area.
2) Find a number of experts willing to contribute. 
3) Designate a leader.
4) Define requirements.
5)  
 

The ordering of (2) and (3) can be inverted.






Ceki Gülcü   
av. de Rumine 5Tel: ++41 21 351 23 15   
CH-1005 Lausannee-mail: [EMAIL PROTECTED]  or
Switzerland [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Listing your e-mail address

[Pier Fumagalli]

Ceki Gülcü <[EMAIL PROTECTED]> wrote:
> 
> Hello,
> 
> Daniel Savarese suggested that e-mail addresses on the "Who we are" page
> should not be listed directly as mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
> but as "foo at bar.com".
> 
> This is will make it harder for spam robots to collect our e-mail addresses.
> For an example of how this will look, see Daniel Savarese's entry.
> 
> I intend to generalize this way of listing e-mail for all entries. If you
> think this is a bad idea, then please let me know. Cheers, Ceki

I like it.. And I believe Jon will love it too :) +1 for me...

Pier

-- 
Pier Fumagalli 
I'm selling my Sony Vaio Z505. Check out 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Listing your e-mail address

[Ceki Gülcü]

Hello,

Daniel Savarese suggested that e-mail addresses on the "Who we are" page should not be 
listed directly as mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] but as "foo at 
bar.com".  

This is will make it harder for spam robots to collect our e-mail addresses. For an 
example of how this will look, see Daniel Savarese's entry. 

I intend to generalize this way of listing e-mail for all entries. If you think this 
is a bad idea, then please let me know. Cheers, Ceki

ps: The URL for the "who we are page" is http://jakarta.apache.org/site/whoweare.html. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]