Peter Donald wrote:
> At 11:20 AM 7/2/2002 +0200, you wrote:
..
>>> There are some commonalities that could be homogenized. ie Phoenix,
>>> myrmidon (and cocoon?) all provide a base directory from which
>>> component can operate. Phoenix and myrmidon also provide the
>>> component with its own name. The keys for these values could
>>> definetly be standardized across the board.
>>
>>
>> Yes, this is something that could/should? be done.
>> Context is something like XML: without a schema it's just making
>> documents unportable.
>>
>>> List of common data values;
>>> * Container version/build number
>>> * component name
>>> * base directory
>>
>>
>> +1+1+1
>>
>>> * common/shared ClassLoaders (at least common to 2 containers anyways).
>>
>>
>> Not as a service?
>
>
> Exposing Kernel services via Serviceable seems nice at first ... but
> soon becomes very ugly. You start having large special cases in your
> code and putting in lots of special cases that is very icky to say the
> very least.
Hmmm...
> ie When you are assembling you need to come up with a new notation that
> saids the container will supply service. ie Usually you say component X
> provides service P to Component Y. You have to also treat them specially
> all through the kernel and it ends up about doubling the container code.
> We experimented doing that with Phoenix for a it but eventually reverted.
Hmmm...
Talking conceptually, the component shouldn't need to "control" the
container, but I understand that some "facitilies" are really needed ATM.
Instead of overloading the Context by making it contain both runtime
objects and kernel services, why not add something like a
KernelServiceable interface?
In this way we have the same semantical value of not having it in
Context, without needing to hack in the service dependency stuff
with special treatment.
Dunno, maybe make a KernelService, and have
MicroKernelService implements KernelService.
StrandardKernelService extends MicroKernelService
EnterpriseKernelService extends StrandardKernelService
This may seem academic and useless, but it's for clarity of the use and
for separation of use case.
--
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]>
