Hi Jon.
Okay. Yes I probably agreed to work on Turbine, too, because sooner or later that
would've been the case anyway.
jon * wrote:
> on 1/21/00 7:10 PM, Jonas Maurus <[EMAIL PROTECTED]> wrote:
>
> > -1 on that (that is, if my vote counts :-) ). Turbine has zero l10n features
> > by
> > now, so you probably would just create confusion with that, don't you think ?
>
> The reason that Turbine doesn't have that feature is because no one has
> implemented it yet.
>
Well, now you have at least a big part of what you need. Problem: removing the
hardcoded reference to org.apache.jyve.localization won't be so easy. I don't know
an elegant way to let the user or framework specify the location of localization
data, at least I can't come up with one right now. Any ideas ?
I'd be quite eager to implement this as soon as we settled on a good solution, as
long as it is a solution which won't break compatibility with mediaphil digital
media's ongoing development. So changing the location of the localization package to
org.apache.turbine is fine with me (after thinking about it for some time) and
making the component more usable for the whole community is something which I feel
good with anyway.
>
> > Basically I'm not in favor of exporting anything from Jyve, because currently
> > there is one LocalizationManager local to Jyve which handles all Jyve-specific
> > stuff, with Jyve-specific resources. Exporting it to turbine would in fact
> > break
> > localization in Jyve as a "standalone product". I almost dare to say that it
> > would be one more unnecessary connection between these two packages.
>
> Excuse me, but Jyve and Turbine are extremely tightly integrated, ON
> PURPOSE. I believe strongly in Turbine and the Turbine model, hell, I wrote
> a good portion of it. There is no "unnecessary connection" between the two
> because they are supposed to be tightly integrated with each other. I really
> don't see this as a negative thing.
>
I didn't say that the Turbine-model is a bad thing. I really appreciate all the work
that has been done by its very active development community. I just think that there
are two different ways of thinking about application logic in general. My approach
would be to say that localization is an application-internal matter and should be
handled by the application itself and contained in the application itself. Including
the Localizationpackage in turbine will probably divide applications which use the
turbine framework in two groups: one with localization support and one without. This
would open the door for a kind of inconsistence in applications developed using the
framework, because the structure of the framework would suggest that localization is
required. Leaving this decision as a whole to the developers would create less
confusion, I think. I hope you understand my point there.
On the other hand, I also support distributing already running and proven systems,
because they offer consistent configuration and less system-dependent "required
knowledge" for the end-user.
As I wrote at the beginning, I'm fine with moving localization to Turbine, but
please try to understand my initial thoughts on the topic.
>
> > Now, if you should go for the turbine-package and remove LocalizationManager
> > from Jyve, it would be quite nice to have a short feature-freeze period with
> > turbine, simply because as you probably know, too, Turbine does not build at
> > the
> > moment, moving in another package into the currently unstable source tree is
> > probably not the best idea and you guys should get rid of the Collection.class
> > mismatch between 1.1 and 1.2 anyway.
>
> The collection mismatch has already been dealt with. Turbine builds just
> fine. Also, just because a single portion of it doesn't build doesn't mean
> that there are going to be issues with the rest of Turbine as a result.
>
> As for feature freeze, Turbine isn't there yet. It will be in about 1-2
> months probably. The reason is that we are adding developers on a daily
> basis. I don't want to stunt that growth right now in any way.
>
My personal approach to things like this was always to prefer a secure and running
system in all changes regarding the code. So I tend to not checking in new code
until problems which keep the code from building properly have been solved. When I
wrote my mail, Turbine didn't build.
>
> > I would really like to discuss these issues over the week-end, because this
> > would enable me to work on this on sunday or at least early next week.
>
> I will be checking email, but I'm pretty strongly for adding localization
> features to Turbine in a generic manner so that there can be maximum
> code-reuse. When you decided to work on Jyve, by nature and association, you
> also signed up to work on Turbine. I thought that I made this pretty clear
> by expressing that you should also understand how Turbine works as well.
>
> -jon
>
Yes. :-)
-Jonas
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
