You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Fernando Padilla <fe...@alum.mit.edu> on 2008/10/31 01:40:18 UTC
proposal to make contributions mutable
So I was just thinking about how tapestry now makes contributions
immutable. And that is currently a pain point of ours because we can't
properly override the settings that we want.
But I was thinking in general, and it sounds like Tapestry should just
open up the contributions to allow people to look at them and modify
then whenever.
One reason is that one of the underpinnings of Tapestry-IoC ( at least
one a long time ago ), was that it's a simple module system because the
assumption is that all modules being loaded are within one server and
all trusted. So if all modules are trusted, why have such a big barrier
as to not allow modules to properly interact through modifying
contributions, when those modifications are trusted and expected too.
Also, if the modules are only trusted a little bit, then allowing
modules to inspect the contributions would be required, to make sure
that no module snuck in without us knowing and added rogue contributions
we did not know about..
Though I like the idea of putting up blinders between modules, it seems
kind of burdensome since it really limits what we can do, and it looks
like module system will never have truly hard lines between them.. so I
vote to take down the blinders around contributions, and let them
visible and mutable from anyone contributing to them, what do you guys
think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: proposal to make contributions mutable
Posted by Fernando Padilla <fe...@alum.mit.edu>.
Also, I would propose to change the ordering of loading of @Submodules
to be in a built up order. So TapestryIoC is at the bottom (first), and
AppModule is at the top (last), with @Submodules being processed left to
right ( first to last ), before the class that refers to them.
This will allow a clean deterministic module loading order, allowing
contributions and overrides to be planned appropriately.
Fernando Padilla wrote:
> that's why I was just saying, making it mutable, period. People can
> look in there, remove, or add contributions, period. :) Let the chips
> fall where they may. Instead of trying to get override rules worked
> out, blah blah blah, just let us do what we need to do. :)
>
> Something like that.
>
> And if multiple people get to contribute/override, then they get to see
> the current state of the configuration and apply their changes
> appropriately..
>
> again, the premise is that these modules and code are trusted to work
> together, else, there are already many ways that they can screw with
> each other ( like a module setting a contribution, on purpose or not,
> and thus not allowing the app to override it ).
>
>
>
>
> Howard Lewis Ship wrote:
>> I've been thinking of adding an override() method to
>> MappedConfiguration and OrderedConfiguration. The major issue is:
>> what if you override() something that doesn't exist? What if you
>> override something multiple times?
>>
>> For OrderedConfiguration: if you override a contribution, what happens
>> to the origionals ordering constraints?
>>
>> On Thu, Oct 30, 2008 at 5:40 PM, Fernando Padilla <fe...@alum.mit.edu>
>> wrote:
>>> So I was just thinking about how tapestry now makes contributions
>>> immutable.
>>> And that is currently a pain point of ours because we can't properly
>>> override the settings that we want.
>>>
>>> But I was thinking in general, and it sounds like Tapestry should
>>> just open
>>> up the contributions to allow people to look at them and modify then
>>> whenever.
>>>
>>> One reason is that one of the underpinnings of Tapestry-IoC ( at
>>> least one a
>>> long time ago ), was that it's a simple module system because the
>>> assumption
>>> is that all modules being loaded are within one server and all
>>> trusted. So
>>> if all modules are trusted, why have such a big barrier as to not allow
>>> modules to properly interact through modifying contributions, when those
>>> modifications are trusted and expected too.
>>>
>>> Also, if the modules are only trusted a little bit, then allowing
>>> modules to
>>> inspect the contributions would be required, to make sure that no module
>>> snuck in without us knowing and added rogue contributions we did not
>>> know
>>> about..
>>>
>>>
>>> Though I like the idea of putting up blinders between modules, it
>>> seems kind
>>> of burdensome since it really limits what we can do, and it looks like
>>> module system will never have truly hard lines between them.. so I
>>> vote to
>>> take down the blinders around contributions, and let them visible and
>>> mutable from anyone contributing to them, what do you guys think?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: proposal to make contributions mutable
Posted by Fernando Padilla <fe...@alum.mit.edu>.
that's why I was just saying, making it mutable, period. People can
look in there, remove, or add contributions, period. :) Let the chips
fall where they may. Instead of trying to get override rules worked
out, blah blah blah, just let us do what we need to do. :)
Something like that.
And if multiple people get to contribute/override, then they get to see
the current state of the configuration and apply their changes
appropriately..
again, the premise is that these modules and code are trusted to work
together, else, there are already many ways that they can screw with
each other ( like a module setting a contribution, on purpose or not,
and thus not allowing the app to override it ).
Howard Lewis Ship wrote:
> I've been thinking of adding an override() method to
> MappedConfiguration and OrderedConfiguration. The major issue is:
> what if you override() something that doesn't exist? What if you
> override something multiple times?
>
> For OrderedConfiguration: if you override a contribution, what happens
> to the origionals ordering constraints?
>
> On Thu, Oct 30, 2008 at 5:40 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
>> So I was just thinking about how tapestry now makes contributions immutable.
>> And that is currently a pain point of ours because we can't properly
>> override the settings that we want.
>>
>> But I was thinking in general, and it sounds like Tapestry should just open
>> up the contributions to allow people to look at them and modify then
>> whenever.
>>
>> One reason is that one of the underpinnings of Tapestry-IoC ( at least one a
>> long time ago ), was that it's a simple module system because the assumption
>> is that all modules being loaded are within one server and all trusted. So
>> if all modules are trusted, why have such a big barrier as to not allow
>> modules to properly interact through modifying contributions, when those
>> modifications are trusted and expected too.
>>
>> Also, if the modules are only trusted a little bit, then allowing modules to
>> inspect the contributions would be required, to make sure that no module
>> snuck in without us knowing and added rogue contributions we did not know
>> about..
>>
>>
>> Though I like the idea of putting up blinders between modules, it seems kind
>> of burdensome since it really limits what we can do, and it looks like
>> module system will never have truly hard lines between them.. so I vote to
>> take down the blinders around contributions, and let them visible and
>> mutable from anyone contributing to them, what do you guys think?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: proposal to make contributions mutable
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been thinking of adding an override() method to
MappedConfiguration and OrderedConfiguration. The major issue is:
what if you override() something that doesn't exist? What if you
override something multiple times?
For OrderedConfiguration: if you override a contribution, what happens
to the origionals ordering constraints?
On Thu, Oct 30, 2008 at 5:40 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> So I was just thinking about how tapestry now makes contributions immutable.
> And that is currently a pain point of ours because we can't properly
> override the settings that we want.
>
> But I was thinking in general, and it sounds like Tapestry should just open
> up the contributions to allow people to look at them and modify then
> whenever.
>
> One reason is that one of the underpinnings of Tapestry-IoC ( at least one a
> long time ago ), was that it's a simple module system because the assumption
> is that all modules being loaded are within one server and all trusted. So
> if all modules are trusted, why have such a big barrier as to not allow
> modules to properly interact through modifying contributions, when those
> modifications are trusted and expected too.
>
> Also, if the modules are only trusted a little bit, then allowing modules to
> inspect the contributions would be required, to make sure that no module
> snuck in without us knowing and added rogue contributions we did not know
> about..
>
>
> Though I like the idea of putting up blinders between modules, it seems kind
> of burdensome since it really limits what we can do, and it looks like
> module system will never have truly hard lines between them.. so I vote to
> take down the blinders around contributions, and let them visible and
> mutable from anyone contributing to them, what do you guys think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org