A
Arne Vajhøj
Every heard a car sales guy call the car he is trying
to sell you for "stylish", "good value for money",
"high quality" etc.?
Arne
Every heard a car sales guy call the car he is trying
to sell you for "stylish", "good value for money",
"high quality" etc.?
Arne
A
Arne Vajhøj
De facto:
lightweight = our product
heavyweight = competitors product
What it should be:
You have already gotten a couple of suggestions for:
weight = level of functionality = level of complexity
I am not sure that this "absolute" measurement is
what people typical see as semantics.
I think that a "relative" measurement fits better:
weight = level of functionality or complexity provided / level of
functionality or complexity necessary to support
Let me clarify with an example:
I consider a Java library with methods implementing
10000 mathematical function with no dependencies to
be lighter than a Java component exposing only 3 methods that require:
* an EJB container
* a message queue
* an Oracle database (due to some PL/SQL SP bing used)
Arne
A
Arne Vajhøj
That is what modularity provides.
Arne
J
Jeff Higgins
Does not yet exist yet to my knowledge.
Very lightweight.
Abstract Application Annotations
Requires only a builder on the development platform.
Develop an application by writing annotated interfaces.
Declarative configuration using (xml?).
@PackagingImpl
interface IApplication
{
@PlatformImpl
void launch(String[] args);
}
@PackagingImpl
interface IPlugin
{
@Uninstall
void install();
@AsService
void start();
@Site
void update();
}
@Persistance
@Typed
interface IData
{
void create();
void retrieve();
void update();
void remove();
}
L
Lew
Arne said:
I tend to agree with Arne's characterization of the terms, and Arved's.
I value Arne's view because it's rooted in ops - "operations" - the area of
build, test and deployment that tends to be messy and labor intensive.
Big-iron shops devote a lot of manpower (i.e., money) to people just running
the systems. The more you mix frameworks with each other, like the app server
with message queues with database with stored procedures with probably JPA and
JMX present in abundance, the more you have to manage to get everything to
play nicely together.
This notion of weight pertains to the programmer, too. It's not all on ops'
shoulders. You work on, say, a JSF application with some Ajax magic and
various auxiliary frameworks for authorization levels in the front end, and
even within just that layer the interactions create effort and careful thought
to manage properly. Similar dangers pertain in the deeper layers - JPA even
within its own universe requires simple idioms to stay light; its dark
corners, exploited fecklessly, can radically complicate analysis of consequences.
An intuitive sense of the integral of (labor times intensity of attention)
over time is what I think of as "weight" in a system.
M
markspace
Ah yes. And we all always believe a company's advertising literature,
right?
S
Stefan Ram
markspace said:
NFSCD: In Swing, »a heavyweight component is associated with
its own native screen resource (commonly known as a peer)«,
while »a lightweight component has no native screen resource
of its own«.
Also in Swing, one sends »a lightweight notification« in
order to notify »that the state has "changed" and require
the listener to respond by sending a query back to the model
to find out what has changed.«, or one might send a
»stateful notification that describes more precisely how the
model has changed«.
J
Jan Burse
What if I want to decide whether my JFrame
is a deamon or not at runtime?
is a deamon or not at runtime?
Jeff said:
J
Jeff Higgins
Shrugs, I'm sure the unknown development team hasn't worked out all the
details yet. :|
D
David Lamb
In ancient times a lightweight/heavyweight meant "done within the
program" vs "done by invoking the operating system, as in threads vs OS
processes, and Swing JComponents vs AWT components. Something could be
both complex and lightweight back then. I suspect you're right that
these days it has become yet another equivalent of "I want you to think
it's better than other people's stuff."
D
David Lamb
An excellent suggestion, but if "marketing" ideas have captured
light/heavy already, we might need a different pair of terms (until they
capture those, too).
J
Jeff Higgins
J
Jan Burse
Jeff said:
Annotations, well, they should
give information to tool chains.
Of course we can try to turn every
framework into a tool. (Also a
kind of business model)
But this doesn't make the resulting
artefact more lightweight.
You will have as a result:
- the framework
+ the annotation definitions (for Java)
+ the annotation processor (at runtime
eventually, so that there is no real
tool step)
And then you loose flexibility, in
case the framework gets locked away
from the end-user (the programmer).
Bye
Bye
A
Arne Vajhøj
I don't think we really need new terms. When one use heavy/light
it is most likely to marketing and/or managers anyway.
Arne