At 08:47 9/4/01 +0200, Leo Simons wrote:
>> true - but cleaning things up takes time - and a fair bit of it to do it
>> good. So I want to have something that is good enough to work with in
>> meantime.
>
>The current version works pretty well, doesn't it? (ment as a real
>question - I have no idea of any issues there may be)
Issues I see with current version:
* No management interface
* developer orientated logging
* I don't like the fact that .sars are unzipped. (almost fixed in local
version though)
>> >I hope I've now clarified that's not what I ment. When you abandon the
>> >notion "phoenix = kernel" you'll arrive at what I ment and we'll
>> >probably agree.
>>
>> I am still not sure - atm I like that Phoenix is an Application Server
>> implementation and nothing more.
>
>Arguments con:
> - I have yet to think of one, really.
* mixing concerns (namely kernel vs non-kernel implementations) and
considering most people will use non kernel implementation then I think
this is significant.
>> okay. I have a huge list of things that need doing and I am just slowly
>> going through it - Berin and Fede probably already know but I have very
>> specific requirements/use-case that I am working towards (DVE/distributed
>> VR simulator/3d-Game server). If I tried to get everything at
>> once it would
>> be -1'ed ;) hence I am just gradually molding it ;)
>
>DVE?
Distributed Virtual Environment (military based most likely)
>Anyway, I think it would help this project tremendously if everyone
>who needs Avalon for something it does not do atm to make those needs
>known to everyone. So, could you elaborate?
I need it capable of being
1. scalable (from low-end clients to high-end servers)
2. runtime loading/unloading (nothing should *ever* go down but must be
able to be reconfigured on the fly).
3. optionally compilable to native code via jet/gcj/other
4. lots of small interacting bits rather than monolithic
5. Solid classpath management
6. Solid security infrastructure (both code based as well as principle based)
7. Fast
Ideally cornerstone will also have some blocks for
a. Role Mapping (ie Does Bob belong to group Administrator?)
b. Authentication
c. Authorisation (ACLs or JAAS style system)
d. Block to manage multicast traffic distribution
Hobbywise I also want to rewrite parts of OS in java. We have
news/telnet/mail/ftp servers in progress but I also want to replace crond
and initd with java based deamons (based on Ant2).
It is getting closer all the time to what I want but there is still a few
kinks to work out.
>To practice what I preach, the only real need I have for Avalon is to
>prove to myself that I can be a real help to an open source project,
>learn how to work in a software development team, and hopefully also
>have something cool to put on my resume =)
don't forget "having fun" ;)
>Things I want to do:
>
>- clean up / simplify phoenix so that it doesn't take weeks to learn
> its internals. Once done doing that, I'll document it too.
excellent
>- I think each lifecycle method (except perhaps dispose()) needs to
> throw its own exception (in the potentially very complex apps built
> on top of Avalon, each method could result in a problem). This needs
> doing, and the exception stuff needs some more documentation as well.
Me too. Add to this the following items and you will have a short-list from
my TODO list ;)
* move init() --> initialize()
* remove Runnable as a lifecycle stage
* Make Context.get() throw an Exception if not found
* Possibly add Mutable versions of Context/Configuration/ComponentManager
interfaces
>- I have ideas on improving the PR/website that I hope to get around
> to before I leave for Down Under.
kewl ;)
>- I would like to see XCommander running on a live server and write
> a chat application (or something similar; real-time) that uses it
> (anyone want to pay for such a server? ;-)
I think something could be arranged if something was operational ;)
>I disagree. Once all interfaces are defined and are stable,
>programming to the interfaces only should be possible. If not,
>the interfaces should not be stable.
We don't have interfaces and factories for Mutable versions of objects. So
components that need to create/modify
configuration/componentmanager/context need to directly manipulate the
Default* objects.
>question: where can I learn about "DAG" (have no idea what it means)?
Directed Acylic (sp?) Graph - we use it as a dependency graph.
Definition basically is;
* a graph with nodes and arcs
* arcs have a direction (ie A->B is not the same as B->A)
* circular dependencies are not allowed (ie A->B->...->A disallowed)
Our nodes are blocks, our arcs include a name of a block and a service it
offers.
>one more: what are the thoughts on the definition of "milestones";
>are we at a stage yet where we can start a 'versioning system' so
>other projects can start depending on that? (it seems like this is
>the right time to think about it and set it up, since we've now
>started talking about "beta" rather than "alpha")
Could be good. I am too lazy to do it and tend to only release stuff when
people bug me enough ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
