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.
> > > My goal is to be able to distribute a "binary" fully-built WAR of Jetspeed
> > > off the web site, which can be dropped in any servlet 2.2 container and tried
> > > out without any configuration tweaking. No more installation questions ! :)
> > > I think it's something that can be of interest for most other Turbine based
> > > project (Jyve, etc...)
> >
> > 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?
> 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 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?
> the value of a few variables (webapp root, etc...) because they're
> servlet container dependant. The resources service may gather at startup
> any referenced variable in the config file and if they are some variables
> which it doesn't know how fill, it throws an exception with the list
> of variables to fill in.
> The Turbine sevlet can then chose to intercept this exception and provide
> a form screen for the user to fill them in...
>
> What do you think ?
Something like that, yes. There should be a list of required properties,
if any of these are missing then the app should produce a screen
that requires an admin password and reports that certain key
properties are missing. This would definitely occur when the
app was installed, and would also occur if someone made a
configuration error. But I would definitely like to work
something where the properties could be retrieved from
multiple sources, an LDAP server ... Dave Bryson has
been thinking about this for Velocity a PropertiesManager
of sorts so that config info can be pulled from any source.
> > 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.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
