Hi Geir,
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
>
>
> Paulo Gaspar wrote:
> >
> > I have been playing with that idea for some time and I believe that a
> > plugable introspection engine should provide his own cache. This means,
> > of course, that a introspection engine factory should be defined and
> > that this one should be used to create an introspection engine instance
> > that should be placed in the internal context.
>
> It doesn't belong in the EventCartridge. That has nothing to do with
> introspection.
We were talking about the possibility of it being a place holder for that.
Maybe the question is:
"Could be changing introspection rules something that you want to do for
a part of your application of for the whole of it?"
> > The default factory would just create an introspection engine instance
> > with the current introspection logic and current introspection cache.
> >
>
> And the fundamental cache should be global, not context local.
I am referring to the fact that you do have a local cache. I am not denying
that you have a global one.
> > Cache objects already need to be created in the context (AFAIK). This
> > way the introspection engine holding the cache gets created in the
> > context.
>
> For a given context, but there should be a global one. The
> context-local cache is a great performance help, as it keeps everything
> from serializing through the global cache.
Same here.
> > The performance impact of having such functionality in place will be
> > unnoticeable (something we already went trough in this list)
>
> Huh? when?
Check the archives. It was an exchange of posts between me and you when I
talked about this the first time.
> > and this
> > will ease the development of alternative introspection strategies.
> > Advantages:
> > - One can easily test new/alternative implementations of the
> > introspection without having to change Velocity's structure;
>
> And if it was pluggable in general, same thing. I don't think this is
> an app level API.
As above, you might be right. It depends of the answer to that question
above.
> > - Customization for different types of introspection (example: getting
> > fields instead of/together with properties, case insensitive, etc.);
>
> That's an advantage of pluggable introspection, not the architecture you
> seemed to just describe.
Sure.
> > - Customization for different resource needs (example: not using the
> > cache for an app with memory restrictions but low performance needs.
>
> Yes, but that's *easily* solvable now. You don't need to rip up the
> guts to do that...
Yes, but with that in place you do not need to change any Velocity code.
You just "plug and unplug".
> > I also think its implementation is not that hard, and I am willing to
> > take a shot at it (already made some experimentation there).
>
> Give it a whirl.
I already worked a bit on it. I stopped when Velocity become a very fast
moving target just before the release.
You people were changing it so fast that I got afraid of coding for
something that could change at any minute.
=;o)
Have fun,
Paulo Gaspar
