10:23 p.m.
First, let me say I think we need to quickly make a statement in the
ChangeLog about this because not having this feature, at least in CSS
resources, is a big shortcoming for Resource loading. Note that Mojarra
currently does have this in *all* resources and I requested Ryan to make
it for just CSS CSS resources to provide a solution for Ted Goddard's
immediate problem regarding the prototype JavaScript library.
EB> OPTION DefaultToOptOut
EB> With this option, we modify Resource.getInputstream() to state that EL
EB> evaluation in Resource files is disabled by default. For simplicity, I
EB> suggest the user convey their intention at a per-application granularity
EB> using a context-param.
This was the most popular option, but no-one was in favor of the context
param; everyone that voted wanted a finer grain solution.
AS> As Jim's email described, the caching behavior is intimately related to
AS> the question of how to handle EL evaluation in resources. I don't think
AS> that these two discussions really are separate matters.
Yes, I see your point that they are related. However, we chose to say
nothing about cache headers and resources in 2.0. Therefore, I think
what we say about cache headers and resources should wait for the next
JCP release of JSF.
On the other hand, as I said above, I think the absence of a way for
resources to refer to other resources is a missing feature. I intended
to specify it in Resource.getInputStream(), but I failed to do so
through an error on my part. Therefore, I'm going to place another
option on the table for inclusion in the ChangeLog.
OPTION ELEvaluatedInCSSOnly
With this option, we modify Resource.getInputStream() to state that EL
evaluation in CSS files is enabled by default. We will state that care
must be taken by the user to ensure that the EL expression always
evaluates to the same thing across multiple requests. We will state
that the user may decorate the ResourceHandler to get more flexibility.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
10:44 p.m.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
+1
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Ed Burns <Ed.Burns(a)Sun.COM>
Date: Fri, 02 Oct 2009 13:23:52
To: <jsr-314-open(a)jcp.org>
Subject: [jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut
First, let me say I think we need to quickly make a statement in the
ChangeLog about this because not having this feature, at least in CSS
resources, is a big shortcoming for Resource loading. Note that Mojarra
currently does have this in *all* resources and I requested Ryan to make
it for just CSS CSS resources to provide a solution for Ted Goddard's
immediate problem regarding the prototype JavaScript library.
EB> OPTION DefaultToOptOut
EB> With this option, we modify Resource.getInputstream() to state that EL
EB> evaluation in Resource files is disabled by default. For simplicity, I
EB> suggest the user convey their intention at a per-application granularity
EB> using a context-param.
This was the most popular option, but no-one was in favor of the context
param; everyone that voted wanted a finer grain solution.
AS> As Jim's email described, the caching behavior is intimately related to
AS> the question of how to handle EL evaluation in resources. I don't think
AS> that these two discussions really are separate matters.
Yes, I see your point that they are related. However, we chose to say
nothing about cache headers and resources in 2.0. Therefore, I think
what we say about cache headers and resources should wait for the next
JCP release of JSF.
On the other hand, as I said above, I think the absence of a way for
resources to refer to other resources is a missing feature. I intended
to specify it in Resource.getInputStream(), but I failed to do so
through an error on my part. Therefore, I'm going to place another
option on the table for inclusion in the ChangeLog.
OPTION ELEvaluatedInCSSOnly
With this option, we modify Resource.getInputStream() to state that EL
evaluation in CSS files is enabled by default. We will state that care
must be taken by the user to ensure that the EL expression always
evaluates to the same thing across multiple requests. We will state
that the user may decorate the ResourceHandler to get more flexibility.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
11:39 p.m.
Since EL evaluation in CSS will continue to have all the problems that I
mentioned earlier for JavaScript (performance and caching), and since
CSS files are fully capable of loading other resources through relative
paths, I'd like to voice mild opposition to the idea.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
-1
I'd instead prefer that we either:
1) Don't evaluate anything in any resource until we sort out the best
way to handle the performance and caching implications
or, as a fallback
2) We evaluate only resource EL in CSS, with a context param that has to
be enabled for it to work (i.e., off by default - since it will decrease
performance and only need to be used in occasional cases). I'd
especially not like to rely on "magic strings" in the file name for this
- there's bound to be a better way implemented in 2.1, and I'd prefer
not to tie us to a brittle mechanism going forward.
But as I said - my opposition to this is only mild - it's certainly not
the problem here that it would be in JavaScript - but once we allow it,
we can't "unallow" it when a better method comes along.
Jim
On 10/2/09 1:23 PM, Ed Burns wrote:
First, let me say I think we need to quickly make a statement in the
ChangeLog about this because not having this feature, at least in CSS
resources, is a big shortcoming for Resource loading. Note that Mojarra
currently does have this in *all* resources and I requested Ryan to make
it for just CSS CSS resources to provide a solution for Ted Goddard's
immediate problem regarding the prototype JavaScript library.
EB> OPTION DefaultToOptOut
EB> With this option, we modify Resource.getInputstream() to state that EL
EB> evaluation in Resource files is disabled by default. For simplicity, I
EB> suggest the user convey their intention at a per-application granularity
EB> using a context-param.
This was the most popular option, but no-one was in favor of the context
param; everyone that voted wanted a finer grain solution.
AS> As Jim's email described, the caching behavior is intimately related to
AS> the question of how to handle EL evaluation in resources. I don't think
AS> that these two discussions really are separate matters.
Yes, I see your point that they are related. However, we chose to say
nothing about cache headers and resources in 2.0. Therefore, I think
what we say about cache headers and resources should wait for the next
JCP release of JSF.
On the other hand, as I said above, I think the absence of a way for
resources to refer to other resources is a missing feature. I intended
to specify it in Resource.getInputStream(), but I failed to do so
through an error on my part. Therefore, I'm going to place another
option on the table for inclusion in the ChangeLog.
OPTION ELEvaluatedInCSSOnly
With this option, we modify Resource.getInputStream() to state that EL
evaluation in CSS files is enabled by default. We will state that care
must be taken by the user to ensure that the EL expression always
evaluates to the same thing across multiple requests. We will state
that the user may decorate the ResourceHandler to get more flexibility.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
Thanks,
Ed
11:56 p.m.
First, I agree with Jim. I think removing the feature entirely until it
can be properly addressed is appropriate.
This works fine in CSS:
a[href $='.txt'] {
padding: 0 20px 0 0;
background: transparent url(images/icons/file-txt.png.xhtml)
no-repeat
center right;
}
Notice the relative reference-URL. This allows resource loading
from any source, as long as you can "do the math" and calculate
the relative URL.
However, on side note...
On Fri, 2009-10-02 at 14:39 -0700, Jim Driscoll wrote:
but once we allow it,
we can't "unallow" it when a better method comes along.
I disagree. I think that backwards compatibility has pluses and minuses,
but we should not rule out removing features that don't make sense
anymore, or changing features that break something in order to achieve a
greater good for the future of JSF. It should be done sparingly, but is
sometimes necessary.
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Creator of:
PrettyFaces: URL rewriting for JSF
PrettyTime: Java elapsed timestamp formatting
12:39 a.m.
On 10/2/09 2:56 PM, Lincoln Baxter, III wrote:
> but once we allow it,
> we can't "unallow" it when a better method comes along.
I disagree. I think that backwards compatibility has pluses and minuses,
but we should not rule out removing features that don't make sense
anymore, or changing features that break something in order to achieve a
greater good for the future of JSF. It should be done sparingly, but is
sometimes necessary.
I had this same discussion with Dan, earlier.
Let's leave aside the wisdom of backward incompatible changes:
Regardless of how you (or I) feel about backward compatibility, Sun
(along with the majority of the EC, including companies like Oracle and
IBM) have always been firmly in the "no backward incompatible change" camp.
That means that you should *always* assume that backward incompatible
changes will be disallowed by forces outside the control of the JSF EG.
Don't put anything in that you aren't willing to live with permanently.
Jim
12:29 a.m.
OK, I need to make a retraction:
It's been pointed out to me that in cases of the resource being in the
classpath, then the Resource EL *is* in fact the only way to get those
files. relative paths won't cut it.
That's a pretty serious reason to have EL evaluation on CSS. I
apologize about the misunderstanding on my part.
So, that means that I need to change my vote:
I'd still like to have only resource EL evaluated.
But, regardless, EL needs to be evaluated, and it's probably common
enough that it needs to be evaluated that having the default be for all
CSS files is not unreasonable.
So,
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
+1
Jim
On 10/2/09 2:39 PM, Jim Driscoll wrote:
Since EL evaluation in CSS will continue to have all the problems
that I
mentioned earlier for JavaScript (performance and caching), and since
CSS files are fully capable of loading other resources through relative
paths, I'd like to voice mild opposition to the idea.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
-1
I'd instead prefer that we either:
1) Don't evaluate anything in any resource until we sort out the best
way to handle the performance and caching implications
or, as a fallback
2) We evaluate only resource EL in CSS, with a context param that has to
be enabled for it to work (i.e., off by default - since it will decrease
performance and only need to be used in occasional cases). I'd
especially not like to rely on "magic strings" in the file name for this
- there's bound to be a better way implemented in 2.1, and I'd prefer
not to tie us to a brittle mechanism going forward.
But as I said - my opposition to this is only mild - it's certainly not
the problem here that it would be in JavaScript - but once we allow it,
we can't "unallow" it when a better method comes along.
Jim
On 10/2/09 1:23 PM, Ed Burns wrote:
> First, let me say I think we need to quickly make a statement in the
> ChangeLog about this because not having this feature, at least in CSS
> resources, is a big shortcoming for Resource loading. Note that Mojarra
> currently does have this in *all* resources and I requested Ryan to make
> it for just CSS CSS resources to provide a solution for Ted Goddard's
> immediate problem regarding the prototype JavaScript library.
>
> EB> OPTION DefaultToOptOut
>
> EB> With this option, we modify Resource.getInputstream() to state
> that EL
> EB> evaluation in Resource files is disabled by default. For
> simplicity, I
> EB> suggest the user convey their intention at a per-application
> granularity
> EB> using a context-param.
>
> This was the most popular option, but no-one was in favor of the context
> param; everyone that voted wanted a finer grain solution.
>
> AS> As Jim's email described, the caching behavior is intimately
> related to
> AS> the question of how to handle EL evaluation in resources. I don't
> think
> AS> that these two discussions really are separate matters.
>
> Yes, I see your point that they are related. However, we chose to say
> nothing about cache headers and resources in 2.0. Therefore, I think
> what we say about cache headers and resources should wait for the next
> JCP release of JSF.
>
> On the other hand, as I said above, I think the absence of a way for
> resources to refer to other resources is a missing feature. I intended
> to specify it in Resource.getInputStream(), but I failed to do so
> through an error on my part. Therefore, I'm going to place another
> option on the table for inclusion in the ChangeLog.
>
> OPTION ELEvaluatedInCSSOnly
>
> With this option, we modify Resource.getInputStream() to state that EL
> evaluation in CSS files is enabled by default. We will state that care
> must be taken by the user to ensure that the EL expression always
> evaluates to the same thing across multiple requests. We will state
> that the user may decorate the ResourceHandler to get more flexibility.
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>
> Thanks,
>
> Ed
>
12:47 a.m.
It's been pointed out to me that in cases of the resource being
in the
classpath, then the Resource EL *is* in fact the only way to get those
files. relative paths won't cut it.
I suppose this would nullify my agreement with you, Jim ;)
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
back to +1 again
--Lincoln
On Fri, 2009-10-02 at 15:29 -0700, Jim Driscoll wrote:
OK, I need to make a retraction:
It's been pointed out to me that in cases of the resource being in the
classpath, then the Resource EL *is* in fact the only way to get those
files. relative paths won't cut it.
That's a pretty serious reason to have EL evaluation on CSS. I
apologize about the misunderstanding on my part.
So, that means that I need to change my vote:
I'd still like to have only resource EL evaluated.
But, regardless, EL needs to be evaluated, and it's probably common
enough that it needs to be evaluated that having the default be for all
CSS files is not unreasonable.
So,
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
+1
Jim
On 10/2/09 2:39 PM, Jim Driscoll wrote:
> Since EL evaluation in CSS will continue to have all the problems that I
> mentioned earlier for JavaScript (performance and caching), and since
> CSS files are fully capable of loading other resources through relative
> paths, I'd like to voice mild opposition to the idea.
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>
> -1
>
>
> I'd instead prefer that we either:
>
> 1) Don't evaluate anything in any resource until we sort out the best
> way to handle the performance and caching implications
>
> or, as a fallback
>
> 2) We evaluate only resource EL in CSS, with a context param that has to
> be enabled for it to work (i.e., off by default - since it will decrease
> performance and only need to be used in occasional cases). I'd
> especially not like to rely on "magic strings" in the file name for this
> - there's bound to be a better way implemented in 2.1, and I'd prefer
> not to tie us to a brittle mechanism going forward.
>
> But as I said - my opposition to this is only mild - it's certainly not
> the problem here that it would be in JavaScript - but once we allow it,
> we can't "unallow" it when a better method comes along.
>
> Jim
>
> On 10/2/09 1:23 PM, Ed Burns wrote:
>> First, let me say I think we need to quickly make a statement in the
>> ChangeLog about this because not having this feature, at least in CSS
>> resources, is a big shortcoming for Resource loading. Note that Mojarra
>> currently does have this in *all* resources and I requested Ryan to make
>> it for just CSS CSS resources to provide a solution for Ted Goddard's
>> immediate problem regarding the prototype JavaScript library.
>>
>> EB> OPTION DefaultToOptOut
>>
>> EB> With this option, we modify Resource.getInputstream() to state
>> that EL
>> EB> evaluation in Resource files is disabled by default. For
>> simplicity, I
>> EB> suggest the user convey their intention at a per-application
>> granularity
>> EB> using a context-param.
>>
>> This was the most popular option, but no-one was in favor of the context
>> param; everyone that voted wanted a finer grain solution.
>>
>> AS> As Jim's email described, the caching behavior is intimately
>> related to
>> AS> the question of how to handle EL evaluation in resources. I don't
>> think
>> AS> that these two discussions really are separate matters.
>>
>> Yes, I see your point that they are related. However, we chose to say
>> nothing about cache headers and resources in 2.0. Therefore, I think
>> what we say about cache headers and resources should wait for the next
>> JCP release of JSF.
>>
>> On the other hand, as I said above, I think the absence of a way for
>> resources to refer to other resources is a missing feature. I intended
>> to specify it in Resource.getInputStream(), but I failed to do so
>> through an error on my part. Therefore, I'm going to place another
>> option on the table for inclusion in the ChangeLog.
>>
>> OPTION ELEvaluatedInCSSOnly
>>
>> With this option, we modify Resource.getInputStream() to state that EL
>> evaluation in CSS files is enabled by default. We will state that care
>> must be taken by the user to ensure that the EL expression always
>> evaluates to the same thing across multiple requests. We will state
>> that the user may decorate the ResourceHandler to get more flexibility.
>>
>> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>>
>> Thanks,
>>
>> Ed
>>
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Creator of:
PrettyFaces: URL rewriting for JSF
PrettyTime: Java elapsed timestamp formatting
5:19 p.m.
I think I agree with Jim's assessment regarding resource-only
evaluation. If we restrict to just that one type of EL expression,
caching becomes much easier.
+1
With regard to relative paths, though, if you're using prefix-mapping,
won't relative paths work? I've not tested it, but it seems like they
ought to:
/myApp/faces/path/to/some/resource.css
which imports ../other/resource.css
That might work, but does require prefix mapping, which, for some odd
reason, I never use. :)
On Oct 2, 2009, at 5:47 PM, Lincoln Baxter, III wrote:
> It's been pointed out to me that in cases of the resource
being in
> the
> classpath, then the Resource EL *is* in fact the only way to get
> those
> files. relative paths won't cut it.
I suppose this would nullify my agreement with you, Jim ;)
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
back to +1 again
--Lincoln
On Fri, 2009-10-02 at 15:29 -0700, Jim Driscoll wrote:
>
> OK, I need to make a retraction:
>
> It's been pointed out to me that in cases of the resource being in
> the
> classpath, then the Resource EL *is* in fact the only way to get
> those
> files. relative paths won't cut it.
>
> That's a pretty serious reason to have EL evaluation on CSS. I
> apologize about the misunderstanding on my part.
>
> So, that means that I need to change my vote:
>
> I'd still like to have only resource EL evaluated.
>
> But, regardless, EL needs to be evaluated, and it's probably common
> enough that it needs to be evaluated that having the default be for
> all
> CSS files is not unreasonable.
>
> So,
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>
> +1
>
> Jim
>
>
> On 10/2/09 2:39 PM, Jim Driscoll wrote:
> > Since EL evaluation in CSS will continue to have all the problems
> that I
> > mentioned earlier for JavaScript (performance and caching), and
> since
> > CSS files are fully capable of loading other resources through
> relative
> > paths, I'd like to voice mild opposition to the idea.
> >
> > ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
> >
> > -1
> >
> >
> > I'd instead prefer that we either:
> >
> > 1) Don't evaluate anything in any resource until we sort out the
> best
> > way to handle the performance and caching implications
> >
> > or, as a fallback
> >
> > 2) We evaluate only resource EL in CSS, with a context param that
> has to
> > be enabled for it to work (i.e., off by default - since it will
> decrease
> > performance and only need to be used in occasional cases). I'd
> > especially not like to rely on "magic strings" in the file name
> for this
> > - there's bound to be a better way implemented in 2.1, and I'd
> prefer
> > not to tie us to a brittle mechanism going forward.
> >
> > But as I said - my opposition to this is only mild - it's
> certainly not
> > the problem here that it would be in JavaScript - but once we
> allow it,
> > we can't "unallow" it when a better method comes along.
> >
> > Jim
> >
> > On 10/2/09 1:23 PM, Ed Burns wrote:
> >> First, let me say I think we need to quickly make a statement in
> the
> >> ChangeLog about this because not having this feature, at least
> in CSS
> >> resources, is a big shortcoming for Resource loading. Note that
> Mojarra
> >> currently does have this in *all* resources and I requested Ryan
> to make
> >> it for just CSS CSS resources to provide a solution for Ted
> Goddard's
> >> immediate problem regarding the prototype JavaScript library.
> >>
> >> EB> OPTION DefaultToOptOut
> >>
> >> EB> With this option, we modify Resource.getInputstream() to state
> >> that EL
> >> EB> evaluation in Resource files is disabled by default. For
> >> simplicity, I
> >> EB> suggest the user convey their intention at a per-application
> >> granularity
> >> EB> using a context-param.
> >>
> >> This was the most popular option, but no-one was in favor of the
> context
> >> param; everyone that voted wanted a finer grain solution.
> >>
> >> AS> As Jim's email described, the caching behavior is intimately
> >> related to
> >> AS> the question of how to handle EL evaluation in resources. I
> don't
> >> think
> >> AS> that these two discussions really are separate matters.
> >>
> >> Yes, I see your point that they are related. However, we chose
> to say
> >> nothing about cache headers and resources in 2.0. Therefore, I
> think
> >> what we say about cache headers and resources should wait for
> the next
> >> JCP release of JSF.
> >>
> >> On the other hand, as I said above, I think the absence of a way
> for
> >> resources to refer to other resources is a missing feature. I
> intended
> >> to specify it in Resource.getInputStream(), but I failed to do so
> >> through an error on my part. Therefore, I'm going to place another
> >> option on the table for inclusion in the ChangeLog.
> >>
> >> OPTION ELEvaluatedInCSSOnly
> >>
> >> With this option, we modify Resource.getInputStream() to state
> that EL
> >> evaluation in CSS files is enabled by default. We will state
> that care
> >> must be taken by the user to ensure that the EL expression always
> >> evaluates to the same thing across multiple requests. We will
> state
> >> that the user may decorate the ResourceHandler to get more
> flexibility.
> >>
> >> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
> >>
> >> Thanks,
> >>
> >> Ed
> >>
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Creator of:
PrettyFaces: URL rewriting for JSF
PrettyTime: Java elapsed timestamp formatting
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
8:07 p.m.
On 2009-10-02, at 2:23 PM, Ed Burns wrote:
OPTION ELEvaluatedInCSSOnly
With this option, we modify Resource.getInputStream() to state that EL
evaluation in CSS files is enabled by default. We will state that
care
must be taken by the user to ensure that the EL expression always
evaluates to the same thing across multiple requests. We will state
that the user may decorate the ResourceHandler to get more
flexibility.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
+1
Confining this evaluation to CSS would appear to lower the risk.
I would like to see the explanation for why relative paths do not
work for classpath resources. Also, I'm not convinced that the
overhead of parsing all CSS on the server is insignificant; has
it been profiled? We really cannot afford to reduce the performance
of JSF at all. Additionally, ResourceHandler decoration sounds like
a convenient extension point, so that should allow this strategy
to be applied at any desired granularity.
Ted.
8:45 p.m.
On 10/05/2009 11:07 AM, Ted Goddard wrote:
On 2009-10-02, at 2:23 PM, Ed Burns wrote:
> OPTION ELEvaluatedInCSSOnly
>
> With this option, we modify Resource.getInputStream() to state that EL
> evaluation in CSS files is enabled by default. We will state that care
> must be taken by the user to ensure that the EL expression always
> evaluates to the same thing across multiple requests. We will state
> that the user may decorate the ResourceHandler to get more flexibility.
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
+1
I prefer to not modify Resource object but move that functionality to
CSS renderer. Suppose you are develop an ResourceHandler extension that
uses SQL database or LDAP as resource storage. If el evaluation is part
of Resource.getInputStream(), you have to implement not only storage
access but dependent of content el evaluation also. In the case of
Renderer, it would be pretty simple because all content-dependent action
will be separate from storage access.
Confining this evaluation to CSS would appear to lower the risk.
I would like to see the explanation for why relative paths do not
work for classpath resources.
If Faces Servlet has suffix-based mapping, not only
path but file
extensions also should be modified. That is horrible for complex
libraries like TinyMCE editor that contains hundreds of references to
scripts, styles and images most of them are assembled in the JavaScript,
so it is not easy to replace these references even with el evaluation
enabled.
Also, I'm not convinced that the
overhead of parsing all CSS on the server is insignificant; has
it been profiled? We really cannot afford to reduce the performance
of JSF at all.
It would not be a significant impact for rare changed values and
proper
caching of evaluation results.
Additionally, ResourceHandler decoration sounds like
a convenient extension point, so that should allow this strategy
to be applied at any desired granularity.
Ted.
5378
days inactive
5381
days old
jsr-314-open-mirror@lists.jboss.org
9 comments
7 participants
participants (7)
-
Alexander Smirnov -
Ed Burns -
Jason Lee -
Jim Driscoll -
Lincoln Baxter, III -
lincolnbaxter＠gmail.com
-
Ted Goddard