Jason van Zyl wrote:
>
> On Mon, 27 Nov 2000, Raphael Luta wrote:
>
> > Jason van Zyl wrote:
> > >
> > > >
> > > > Never found the time to download it and move jetspeed on a TDK base :(
> > > > It's in my TODO list...
> > >
> > > I would be happy to work with you on this! All I've been working
> > > on lately is the TDK in preparation for making a new version
> > > of the sandbox for Scarab. Torque is now fully integrated: every
> > > last bit of SQL required by Turbine is automatically generated
> > > by Torque, the target database is created, and the SQL is inserted.
> > > All the Peers for your project (as defined in an XML schema) are
> > > auto generated and compiled.
> > >
> >
> > Jetspeed doesn't use the Turbine Peer model right now so Torque support
> > is not currently very important for the project. I don't know what
> > other advantages there would be to move Jetspeed as TDK.
>
> Uniformity with other Turbine projects, as the TDK will be
> promoted as the primary development model for Turbine apps. Of
> course, you are free to do whatever you want, but if the three
> current big Turbine apps (Jyve, JetSpeed, Scarab) used the same
> model then it would be a lot easier to add dev/deployment
> tools that all projects can use. Scarab currently uses
> the TDK and so does the new version of Jyve.
>
Yes, I agree that TDK integration is a goal for Jetspeed, you don't
have to hammer the point more :)
> > >
> > > I will get rid of every last hard-wired path, so deploying TDK apps
> > > will be seemless. I am almost there, the TDK will produce apps that
> > > can be dropped in any contain on any path. I am in full agreement
> > > with you that any changes that are required in Turbine to make this
> > > happen are ultimately required to make deployment simple.
> > >
> >
> > I think getting rid of the non-relative path in every component is the wrong
> > way to approach the problem because:
> > - you'll have to make sure every new component doesn't introduce new
> > path issues
> > - if increase the code complexity of every component and may tie them
> > to a servlet path resolution mechanism
>
> If there are any path issues, would it not be appropriate to
> use the servlet path resolution mechanism to keep everything
> self contained?
>
Definitely, but I think these resolutions are better handled by the
resources service than by each individual component.
> > IMO, the better approach is to allow TurbineResources to flexibly deliver
> > to the components their conf properties in whatever format is natural for
> > them. It's quicker to implement and will stay correct whatever new components
> > are introduced.
>
> Right, is this the interface you were talking about earlier? The
> retrieval of properties from any source? So you could retrieve
> your properties from an LDAP server, database, or whatever?
>
I just proposed to make the resources service pluggable (it's not the case
currently) so that I can write my own implementation if I need.
LDAP, DBMS, whatever configurations will need to be implemented by someone
else but at least will be possible.
> > > I would also like to add something to Turbine where the initialization
> > > of the app can be done via a web browser. Drop the WAR file in
> > > the container. When the app runs for the first time, it will
> > > "know" that it's not configured. Present a form to the administrator:
> > > let them pick the target database, initial passwords and whatever
> > > else then create the database and all the SQL required for the
> > > app to run. I can already create a database app in 5 seconds
> > > using a Linux/MySQL combination and adding support for other
> > > platform/database combinations should be easy.
> > >
> >
> > I like that ! This can be implemented as by using my
> > VariableTurbineResources implementation: by default, Turbine knows
>
> Where is your VariableTurbineResources implementation?
>
Coming soon with the patches for TurbineResources.
I think the VariableTurbineResources will end up in Jetspeed CVS at first
because my implementation require Servlet 2.1 or more.
>
> > > I would like to make deploying turbine apps dead simple
> > > to deploy! For me the TDK is about easy development and
> > > easy deployment. I'm not far from this being a reality and
> > > I would love to see Jyve and Jetspeed use the TDK.
> > >
> >
> > If we have the same goals, we're bound to converge sometimes soon.
>
> I think so, but I think you should be working toward using
> the TDK, if you see deficiencies in the TDK model then you
> should help to fix those so that all Turbine developers can
> benefit. I don't see any point in not using the TDK.
>
I agree, it's just that moving to TDK is not a high priority
right now. It will be when we are closer to a new milestone release.
However, if you want to port Jetspeed as a TDK app right now, you're
more than welcome ;)
--
Rapha�l Luta - [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
