Hello, Augusto
I've tried to summarize, but failed. Need some help.
The first meta-problem I've faced is that
TracDev/ComponentArchitecture is missing a Chapter about component
lifetime. I.e. what happens with components when Trac is loaded, when
ComponentManager instantiates them, what happens when it just
enumerates them, what methods are called at which point?
The summary with questions. Please correct.
trac.ini allows to choose between components implementing the same
extension point.
components with extension point should offer user a choice.
components with extension point provide an option to chose
implementing component in trac.ini using trac.config.ExtensionOption
or trac.config.OrderedExtensionsOption
trac "loads" all components on startup.
1. what does "loads" mean?
? enumeration of available component class names
? building list of dependencies among class names according to
extension point -> implementation
? initializing components using dependency chain by creating
objects and calling their __init__ method
trac reads configuration.
2. does it need components to be loaded at this stage to parse config
trac configures components
3. are there any layers of component configuration?
? trac decision if component should be loaded based on internal
architecture
? trac decision if component should be loaded based on some
general permissions
? trac decision if component should be loaded based on explicit
component configuration
? component decision if it should be loaded
components with extension points may choose component that implement
it among available choices based on configuration
everything is set. request processing start execution
If all above is correct (that I am really unsure of), then your
proposal for components that should choose implementation for their
extension point without initializing all other components can have two
alternatives (depending on actual Trac loading sequence):
1. load configuration before components are "loaded", analyze
dependency chains and "load" only required components
2. postpone initialization of components (i.e. calling __init__ method) until
2.1 implementing component is used for the first time
2.2 extension point component decides to choose one (and discard all
others from init chain)
Is everything above is right?
--
anatoly t.
On Wed, Dec 30, 2009 at 1:42 AM, Augusto Roccasalva
<[email protected]> wrote:
> Hello list,
>
> First of all, thanks for this great software!.
>
> I'm working on a personal project that use Trac architecture and I found a
> thing that can be improved in components implementation.
>
> When we use 'ExtensionOption' or 'OrderedExtensionOption' from config module
> as component option, all components that declare implement certain interface
> are instantiated if wasn't before. This means that components that are not
> declared as desired extension are initialized anyway.
>
> Some components maybe needs check for resources to work. That checks can be
> done in intialization of that component. But if all components are initialized
> even if we don't want to use that component, these resources are checked (or
> taked).
>
>
> Simple use case for clarification: a session component that optionaly use
> differents backends to store data.
>
> class ISessionStore(Interface):
>
> def load(self, session_id):
> "Retreive session object"
>
> def save(self, session_object):
> "Store session object"
>
> class SessionComponent(Component):
>
> session_backend = ExtensionOption('sessions', 'backend', ISessionStore,
> 'MemorySessionStore', """Session backend to store data.""")
>
> def process_request(self, request):
> sess = self.session_backend.load(request.session_id)
> # ... do something with sess object
> self.session_backend.save(sess)
>
> class MemorySessionStore(Component):
> implements(ISessionStore)
>
> def __init__(self): # initialization
> self._data = {}
>
> def load(self, session_id):
> return self._data.get(session_id, None)
>
> def save(self, session_object):
> self._data[session_object.id] = session_object
>
> class FilesystemSessionStore(Component):
> implements(ISessionStore)
>
> def __init__(self): # initialization
> # ... check write permission on filesystem
>
> def load(self, session_id):
> # ... load session from filesytem
>
> def save(self, session_object):
> # ... save session to filesytem
>
> class DatabaseSessionStore(Component):
> implements(ISessionStore)
>
> def __init__(self): # initialization
> # ... check connection to specified database and connect
>
> def load(self, session_id):
> # ... use previously opened connection and load session
>
> def save(self, session_object):
> # ... use previously opened connection and save session
>
> and then in the configuration file we can have:
>
> [sessions]
> backend = FilesystemSessionStore # I don't have database server :(
>
> thus DatabaseSessionStore.__init__() is never called because I know that we
> have not database server.
>
>
> This can be done with current implementation if we add some extra code for
> initializations things, but this is unnatural when we have __init__() method
> for those things.
>
> I have elaborated a little patch that fix this, initializing only components
> that are used. This patch is delicated because touch some important files in
> the project (trac/core.py and trac/config.py).
>
> Before open a ticket in Trac trac I want to know your opinions about this.
>
> Sorry for my basic english.
>
> Best Regards,
> -- Augusto
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
