Introductions

[Berin Loritsch <bl...@apache.org>]

My name is Berin Loritsch and I am the Release Manager for the Jakarta Avalon
projects, as well as a committer on the Cocoon projects.  Recently, my employer
asked me to develop a solution using Turbine.  The reason was two-fold:  Cocoon
documentation is still on the slim side, and the learning curve is high.  I am
still very dedicated to the Avalon and Cocoon projects, however I am open to
how turbine does things.

I am interested in helping Turbine integrate more seamlessly with Cocoon, and
will be willing to do some of the hard work.  I am intimately familiar with
the architecture of Cocoon and Avalon, so I would be able to offer suggestions
that will provide a smooth migration path to something that is embeddable.

One of the things that I would like to work on in Turbine (once I am familiar
with it) is to update the configuration system.  I find property files to be
tedious, and can provide some insights on how to maintain backward compatibility
while moving to an XML based configuration.  While there are "competing"
portions of Turbine and Cocoon (notable Actions and DB connection pooling),
I can help with providing hooks to allow the use of Turbine utilities.

I hope you will find my contributions both worthwile, and valuable.  I know
there will have to be some cooperation between the projects, and I can provide
that cooperation.  I will post my user related questions to the user list,
but any proposals I will post here.

Re: Introductions

[Jon Stevens <jo...@latchkey.com>]

Welcome Berin! :-)

-jon


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

Re: Introductions

[Jason van Zyl <jv...@apache.org>]

On 7/2/01 2:50 PM, "Berin Loritsch" <bl...@apache.org> wrote:

> Jason van Zyl wrote:
>> 
>> On 7/2/01 2:30 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>> 
>>> Or the other way around.  In the beginning, I will persue the path of least
>>> resistance.  If it is easier to embed Turbine, I will go that route.  If it
>>> is easier to embed Cocoon, then you get the idea.  I need to wrap my head
>>> around the way Turbine works, so that will take me a few days.
>> 
>> What aspect of Turbine did you want to use with cocoon? The view
>> portion? I assume cocoon already has it's own db connection code
>> that comes from avalon.
> 
> I was thinking the File upload and ACL code for starters.  The MaybeUpload jar
> lives up to its name, but I was also thinking of creating a
> DataSourceComponent
> that wrapped the Turbine connection code.

Cool.
 
>> I would look at HEAD. It will be changing over the next few days,
>> but it's a glimpse of what's to come.
> 
> I was going to use the TDK to get started.  I will look at what is in CVS as
> well.

I can send you 2.2 TDKs if you want something that works out of the box
and represents more accurately where Turbine is going. I'd be glad to
help you try and integrate Turbine into Cocoon or whatever the path
may be :-)

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



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

Re: Introductions

[Berin Loritsch <bl...@apache.org>]

Jason van Zyl wrote:
> 
> On 7/2/01 2:30 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
> > Or the other way around.  In the beginning, I will persue the path of least
> > resistance.  If it is easier to embed Turbine, I will go that route.  If it
> > is easier to embed Cocoon, then you get the idea.  I need to wrap my head
> > around the way Turbine works, so that will take me a few days.
> 
> What aspect of Turbine did you want to use with cocoon? The view
> portion? I assume cocoon already has it's own db connection code
> that comes from avalon.

I was thinking the File upload and ACL code for starters.  The MaybeUpload jar
lives up to its name, but I was also thinking of creating a DataSourceComponent
that wrapped the Turbine connection code.

> I would look at HEAD. It will be changing over the next few days,
> but it's a glimpse of what's to come.

I was going to use the TDK to get started.  I will look at what is in CVS as
well.

Re: Introductions

[Jason van Zyl <jv...@apache.org>]

On 7/2/01 2:30 PM, "Berin Loritsch" <bl...@apache.org> wrote:

> Jason van Zyl wrote:
>> 
>> Some have told us that the Turbine documentation is a little on the slim
>> side too!
> 
> There is a bit more than on Cocoon though.
> 
>>> I am intimately familiar with
>>> the architecture of Cocoon and Avalon, so I would be able to offer
>>> suggestions
>>> that will provide a smooth migration path to something that is embeddable.
>> 
>> You mean embedding Cocoon in Turbine?
> 
> Or the other way around.  In the beginning, I will persue the path of least
> resistance.  If it is easier to embed Turbine, I will go that route.  If it
> is easier to embed Cocoon, then you get the idea.  I need to wrap my head
> around the way Turbine works, so that will take me a few days.

What aspect of Turbine did you want to use with cocoon? The view
portion? I assume cocoon already has it's own db connection code
that comes from avalon.

I would look at HEAD. It will be changing over the next few days,
but it's a glimpse of what's to come.


-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



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

Re: Introductions

[Berin Loritsch <bl...@apache.org>]

Jon Stevens wrote:
> 
> on 7/2/01 11:30 AM, "Berin Loritsch" <bl...@apache.org> wrote:
> 
> > Or the other way around.  In the beginning, I will persue the path of least
> > resistance.  If it is easier to embed Turbine, I will go that route.  If it
> > is easier to embed Cocoon, then you get the idea.  I need to wrap my head
> > around the way Turbine works, so that will take me a few days.
> 
> Berin,
> 
> I think that you will find that merging the two together will be difficult
> because both of them attempt to control the URI space.
> 
> If you take a few steps back and try to realize what Cocoon is actually
> doing along side with what Turbine is actually doing, you will see that
> Cocoon will play nicely with Turbine as the "View" portion of Turbine.
> 
> I just saw your other posting come by stating that you would like to use the
> Services. In that case, you don't need anything more than to use the
> TurbineConfig object to initialize Turbine with the right
> TurbineResources.properties file and then go from there by using the
> Services directly within your other code.

:)  That is what I am trying to determine.

Re: Introductions

[Jon Stevens <jo...@latchkey.com>]

on 7/2/01 11:30 AM, "Berin Loritsch" <bl...@apache.org> wrote:

> Or the other way around.  In the beginning, I will persue the path of least
> resistance.  If it is easier to embed Turbine, I will go that route.  If it
> is easier to embed Cocoon, then you get the idea.  I need to wrap my head
> around the way Turbine works, so that will take me a few days.

Berin,

I think that you will find that merging the two together will be difficult
because both of them attempt to control the URI space.

If you take a few steps back and try to realize what Cocoon is actually
doing along side with what Turbine is actually doing, you will see that
Cocoon will play nicely with Turbine as the "View" portion of Turbine.

I just saw your other posting come by stating that you would like to use the
Services. In that case, you don't need anything more than to use the
TurbineConfig object to initialize Turbine with the right
TurbineResources.properties file and then go from there by using the
Services directly within your other code.

Thanks,

-jon


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

Re: Introductions

[Berin Loritsch <bl...@apache.org>]

Jason van Zyl wrote:
> 
> Some have told us that the Turbine documentation is a little on the slim
> side too!

There is a bit more than on Cocoon though.

> > I am intimately familiar with
> > the architecture of Cocoon and Avalon, so I would be able to offer suggestions
> > that will provide a smooth migration path to something that is embeddable.
> 
> You mean embedding Cocoon in Turbine?

Or the other way around.  In the beginning, I will persue the path of least
resistance.  If it is easier to embed Turbine, I will go that route.  If it
is easier to embed Cocoon, then you get the idea.  I need to wrap my head
around the way Turbine works, so that will take me a few days.

Re: Introductions

[Jason van Zyl <jv...@apache.org>]

On 7/2/01 2:00 PM, "Berin Loritsch" <bl...@apache.org> wrote:

> My name is Berin Loritsch and I am the Release Manager for the Jakarta Avalon

Hi!

> projects, as well as a committer on the Cocoon projects.  Recently, my
> employer
> asked me to develop a solution using Turbine.  The reason was two-fold:
> Cocoon
> documentation is still on the slim side, and the learning curve is high.  I am
> still very dedicated to the Avalon and Cocoon projects, however I am open to
> how turbine does things.

Some have told us that the Turbine documentation is a little on the slim
side too!

> 
> I am interested in helping Turbine integrate more seamlessly with Cocoon, and
> will be willing to do some of the hard work.

Many people have asked about a Cocoon service in Turbine so I'm sure it
would be welcomed!

> I am intimately familiar with
> the architecture of Cocoon and Avalon, so I would be able to offer suggestions
> that will provide a smooth migration path to something that is embeddable.

You mean embedding Cocoon in Turbine?
 
> One of the things that I would like to work on in Turbine (once I am familiar
> with it) is to update the configuration system.  I find property files to be
> tedious, and can provide some insights on how to maintain backward
> compatibility
> while moving to an XML based configuration.  While there are "competing"
> portions of Turbine and Cocoon (notable Actions and DB connection pooling),
> I can help with providing hooks to allow the use of Turbine utilities.

I was planning to use the Resources package in the commons to allow
configuration of Turbine from any source. The commons digester would
definitely allow the configuration of turbine via XML and the
ExtendedProperties is what we are currently using. I definitely think
it would be beneficial to have an XML configuration, along with being
able to configure turbine from a db, or ldap say.
 
> I hope you will find my contributions both worthwile, and valuable.  I know
> there will have to be some cooperation between the projects, and I can provide
> that cooperation.  I will post my user related questions to the user list,
> but any proposals I will post here.

Turbine is changing a lot right now, but I'm hoping to get an alpha out
of 2.2 in a couple of weeks for people to look at. Talk to you soon!

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



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