Leo Sutic wrote:
Stephen,Yes, I feel the same way.
your point is taken that all operations that are not a lookup of a
constant value based on a key (such as getHomeDirectory)
can be seen as a peer service.
First, everything can be seen as a peer service. We don't really
need the Configurable interface. Instead, one could lookup a
configurator service:
interface Configurator {
Configuration getConfiguration ();
}
and use the returned Configuration. The container would ensure you
got the correct config.
However, while it reduces the set of classes one has to deal with
("everything is a service") there are practical issues with this.
Peter D. mentioned a few of them here:
http://marc.theaimsgroup.com/?l=avalon-dev&m=103809692826408&w=2
and I believe he's right.
My analysis would be that the real problem *is* the Context interface.
Specifically, that it is a total mess. What is it for? Constant value lookup?
Container specific services only? Container provided services in general?
If anything, this is something that has to be solved before we go on.
The Context is something that has been used in the past and is used now in many ways, like a sort of catchall thing.
"Hey, where do we put this? Use the Context".
I even wonder why we have a Context interface at all, since we are casting as we do with Services (and there we have removed the Component Interface). Context is for many a happy ComponentManager.
Now, in real life, what is a Context for?
Let me try to make a simple example.
Let's say that I make my famous GooServer using Avalon. It's an HTTP server, and it sends every single request to a chain of Goolets, that are Avalon Components. The Server itself is a simple GooContainer.
,------------GooContainer---------------------.
| |
| | |
| /-----GooLet1-------\ | ---------- |
GooRequest | | | |-| | |
------->------------ goo(GooRequest) | | | Storage| |
| | |---| | Service| |
| ------ GooResponse | | | | |
| | | | | ---------- |
| | \-------------------/ | |
| | | ---------- |
| V |-| | |
| | | | Search | |
| | /-----GooLet2-------\ | | Service| |
| | | | | | | |
| ------ goo(GooRequest) | | ---------- |
GooResponse | | |---| |
-------<------------ GooResponse | | ---------- |
| | | |-| | |
| \-------------------/ | |Template| |
| | |Service | |
| | | | |
| | ---------- |
| |
,----------------------------------------------.
When a GooRequest arives, the simple GooContainer intantiates the Goolets that its Configuration specify, runs through the initial lifecycle Interfaces (giving them also itself as a reference), and calls the
GooResponse goo(GooRequest)
on them one after the other.
Each GooLet can be Composable, thus have a reference to Services that are provided. As you see, there is no Context (yet).
Imagine though that you have 3, 4, 5 requests, and concurrent requests. Each Service is the same object as before, thus *is not scoped per chain invocation*.
Now the GooLet2 wants to tell Goolet1 something. It can only via the GooResponse-GooRequest, because it's the only object in the above scenario that is per-request.
Hmmm, no Context yet...
NOw I want to track sessions between invocations.
Services are always the same.
Requests are atomic... I need a Context. Something that gives me information sharing per session.
Now, what is a Context?
If it's a bag to put values common to all Goolets, it's a Service.
If it's to be shared by all Goolets in the same invocation it's a Request.
So it seems to be a bag to hold info between invocations but pertaining to a certain criteria (session for example).
So
X requests for X invocations
N services for X invocations
Y contexts for X invocations
Where
Y<=X
N not related to X || Y
This is not how Context is used now in most cases. It's used to get a directory for example, which in this case seems to be a Service... so?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
