hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Gibson" <Steve.Gib...@cowww.com>
Subject RE: [SPAM] - Working on something nifty with translators - Email has different SMTP TO: and MIME TO: fields in the email addresses
Date Tue, 13 Jul 2004 14:07:28 GMT
This sounds pretty cool, but doesn't this undermine a some of the
reasons for having configuration-points and contributions?

I have services that consume a properties file. Instead of messing
around with a translator, I would be tempted to set it directly for my
service. Later on, I have another service that also wants to consume
that property file, and I then would have do make it into a
configuration point, create a translator and all that stuff...

I am just throwing thoughts in here. I know this would solve a lot of
peoples problems. Maybe there is some common ground that can simplify
both areas...

Steve Gibson

-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Tuesday, July 13, 2004 9:54 AM
To: hivemind-dev@jakarta.apache.org
Subject: [SPAM] - Working on something nifty with translators - Email
has different SMTP TO: and MIME TO: fields in the email addresses


Did a little thinking outside the box recently w.r.t. BuilderFactory.

Dieter wanted to "subclass" BuilderFactory to add new parameter
elements ... elements that made it easier to set service properties.

He wanted to do this because BuilderFactory has a fixed number of
elements, corresponding to a fix set of acceptible types: string,
long, service, configuration, etc.

But what if the shoe was on the other foot?

What if BuilderFactory had a set-object element that could, magically,
take any type of object, and didn't care where it came from? Maybe its
an object, or a configuration, or a service ... or even a property
obtained from a service?

The system I'm working on will allow that.

A prefix on the contribution will allow its type to be interpreted,
i.e.:

service:foo.bar.Baz
instance:org.foo.bar.Boo
configuration:foo.bar.Blip
bean:foo.bar.Baz:fred
service-property:foo.bar.Baz:glip

Those are examples off the top of my head.

Of course, there'll be a configuration to define prefixes, and
services to implement each type of prefix.  If the one you need isn't
available, then you'll be able to supply your own.

Basically, it's a meta-level above translators. 

This will remove a lot of redundancy in some contributions: for
example, the Pipeline schema is doubled: to allow service
contributions, or contributions from bean factories.


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org


Mime
View raw message