james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Benett <char...@benett1.demon.co.uk>
Subject Contributions (Was Re: cvs commit: jakarta-james/src/conf spool.properties)
Date Fri, 03 Aug 2001 08:32:01 GMT
Oki DZ wrote:
> 
> On Thu, 2 Aug 2001, Charles Benett wrote:
> 
> > I haven't tried it, but it should be as simple as ./build.sh
> > -Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true
> 
> I did that when I tried to use Serge's noparse-mimemessage. But that's
> the command for getting the appropriate files in the build directory (ie:
> not for submission).
> 
> As I understand it, the proposal directories contain the source which
> would eventually become included in the distribution.

Correct

> I was thinking about
> a "contrib" directory, where the source files would be in there and be
> used according to the user's needs. For example, mailets. I believe that
> there would be more mailets being written (by non-committers), and I don't
> think that putting them all in the .sar file would be useful. So, the
> contrib directory would be a nice place to put them; and then have the
> mailets included by executing the build.sh command with the appropriate
> options.
> 
> That's just about semantics (different rendering of the word "proposal"),
> though; if what is meant with "proposal" also represent what I meant with
> the "contrib" above, then there's no reason in creating a new directory.
> We can use what's already available. But... I don't think that creating a
> "contrib" directory would be costly. Besides, it would make ones more
> relaxed in submitting codes; they don't have to be committers.
> 
> Well, I believe that I still have something missing; if you submit source
> files to the CVS, should the package names have "org.apache" in them? I
> guess not. If it is, then it's too restrictive. If the restriction should
> be in place, then the "contrib" might be an acceptable solution; so that
> ones could submit codes with any package names they like. And also, the
> submitted codes don't have to be working out of the box; eg: a submitter
> might upload a mail repository that expects totally different database
> schema for the repository table.
> 
> The mail repository may not be needed by most of the James users, but
> somebody might badly need it given the same environment where James is
> expected to be run. Think about a mail repository that implements direct
> calls to MySQL client libraries via JNI (Java Native Interface) to speed
> things up. I believe such repository doesn't belong to the main branch in
> the CVS; the code wouldn't be that portable, tightly tied to the operating
> system where the repository should be run. But it would be really nice if
> the code is accessible by the James users at large, and it would need a
> nice place where to put it.

If the code is contributed to james, ie the copyright is assigned to the
Apache Software Foundation, then I think it should go in the main source
with an org.apache.james.* package.  There is then a separate question
of comiling sars with the particular set of classes someone wants. But
the default distribution would probably have the whole lot.

If the copyright is not assigned to the ASF, I'm not sure we can include
it in the cvs repository. (We'd need to check, if that is what you are
proposing.) If we can't include it in the repository, maybe we could
have a webpage that lists james-compatible code and links to sites where
they can be downloaded.

Clearly, a straight contribution would be preferable.

> 
> > BTW, what are you working on?
> 
> MySQLMailRepository, MySQLSpoolRepository, and UsersMySQLRepository that
> implement Turbine's db connection pooling. The spool repository implements
> a global cache that temporarily stores the list of the messages that
> resides in the spool; so that when the spool repository's accept() method
> gets invoked (after the first invocation), there would be no additional
> SQL query sent to the db server. This would make the spool works faster I
> believe, even if the db pooling is already there.

In general, I have no problem with james having alternative
implementations, so long as there are good reasons for each one. 
If you are happy to assign contribute the code to apache and people on
the list who know more about dbs than me agree, we could include your
stuff as well as Serge's.

Charles

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message