Johan,
I'm not active on James development but......
This whole business has been discussed multiple times in the Avalon list
as the K/HC/CAPI issue.
Phoenix is the Kernel (K), the frame work interfaces etc are the Client
API (CAPI) and the blocks are hosted components (HC).
In the case of JAMES an others there is a *second* K/HC/CAPI arrangement
on top of Phoenix. JAMES is the Kernel and has a Client API. Maillets
are Hosted Components.
In terms of classloader visibility HC *should* be able to see CAPI but
not K. This situation has yet to be integrated into Phoenix.
In answer to your questions:
1) To build a common utility for this into phoenix would be very
difficult I think.
2) dunno.
3). There are two other Phoenix using projects that provide "hosting"
for things equivalent to maillets:
Jesktop: Once this boots on top of phoenix, it allows the dynamic
installation of GUI applications
and mounts each in a separate classloader. Wike windows install
without reboot.
Enterprise Object Broker. Slightly different : This mounts separate
classloaders at boot time only.
It is still out of the control of Phoenix, and later in its
development cycle it will support hot
installation like Jesktop.
These two do not share code despite both being written
susbstantially by me.
- Paul
---
Paul is hoping the JAMES team will come up with an RFC that solves the
inherent problems in SMTP that currently allows spammers to act with
impunity. Paul thinks this RFC should chart a path that renders all
current STMP servers wholly incompatible with that future.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
