Sorry but what the start of this thread ?
-
Henri Gomez ___[_]____
EMAIL : [EMAIL PROTECTED] (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-----Original Message-----
>From: Kopp, Thomas (DIALOGIKA) [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, June 28, 2001 8:11 PM
>To: '[EMAIL PROTECTED]'
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
>Subject: RE: [JSR-96-Members] JSR-096 (Java Daemon API) critique...
>
>
>Pier,
>you send a negative feedback on things you have agreed to when
>we met in
>London.
>
>Your critics contains an entire paper about daemons and
>services but you
>only say that the current spec does not address VM issues.
>I have the problem that I do not know, which technical aspect
>you refuse.
>Please, tell me more detailed and technical arguments.
>If you let me know these issues we might be able to discuss
>and solve the
>problems on a technical level.
>
>In London we agreed that the modules we ship consist of
>- a Java block, which is subject of the API spec and
>- a platform-specific block, which can hardly be specified for each
>individual platform.
>
>Hence, we said that we try to put a maximum of functionality
>in the Java
>building block, which can exactly be specified and tested.
>In addition, we would give suggestions, how to use the control
>side of the
>API without defining, how this should be done in detail.
>In fact, we even cannot define it due to the broad variety of existing
>platforms.
>
>This partition of the original proposal in separate building
>blocks seemed
>to be completely natural and there was no critics about this packaging
>model. The outcome still fully addresses the issue of the
>initial JSR. It
>now also addresses a lot more due to long-term reflections
>about an ideal
>design of the API.
>
>YOU said YES to this model and YOU proposed that Apache would
>supply the
>native platform side for the major OS, i.e. Win32, Solaris,
>Linux. Nobody
>asked you to do so.
>
>
>During the first phase of JSR96, there was a significant
>number of requests
>concerning remote management support.
>Since this issue is addressed by JMX for the Java platform, we further
>agreed that we would also provide a JMX-enabled control side to satisfy
>these requirements. The current packaging model provides a
>simple way to
>address these issues.
>
>Everything that has been initially proposed is still addressed
>except for a
>lot more, which I didn't even think about in the beginning.
>We did not leave the roots. In contrast, we are only able to
>do a lot more
>with some more careful thinking about how we realize individual aspects
>think we shouldn't be afraid of being more powerful than it
>was initially
>planned.
>
>In addition, the Java community has many different interests. Since, we
>supply infrastructure for the community and not only for one individual
>aspect, we have a certain responsibility to take a careful choice.
>
>
>Pier, YOU wanted to elaborate a security concept together with Damon.
>Nothing happened for weeks. (We met at 21 April.) I do not criticize if
>somebody has not the time to contribute. I know that everybody
>has a hard
>job and I understand if there is no time left to contribute to
>a specific
>JSR.
>
>But, I think it can also be understood if I as the spec lead
>try to move the
>project forward. So I proposed a security concept elaborated
>together with
>the resources available, i.e. with my colleagues, which are also valid
>expert group members like you or anybody else in this group.
>
>These were valid technical discussions, like you discuss
>things with your
>colleagues in Apache group. Nothing is hidden. Every important
>result of any
>person-to-person discussion automatically goes to the expert group via
>mailing lists, phone calls or the spec. This is ordinary
>working style. We
>cannot have meetings with the whole expert group for each
>detail. So do you
>think that I shouldn't talk personally to individual expert
>group members
>anymore?
>
>
>In addition, versions of spec are out since one week after our London
>meeting. There was nearly no feedback since that time.
>So, I must assume that there is a kind of agreement if I don't get any
>feedback at all.. Consequently, I have a problem to understand
>this sudden
>360-degree-turn-around. What is the real problem?
>
>Please, tell me what functionality you need, cannot be fulfilled by the
>current spec in a suitable way?
>Since the beginning of this JSR I was continuously thinking
>about a lot of
>aspects and use cases. In addition, many issues of internet
>discussions,
>expert group discussions and our meeting brought a lot of
>different aspects.
>So I tried to recognize and combine all aspects in the spec.
>An FAQ was
>added to explain and justify why a certain requirement
>resulted in a certain
>design.
>
>This was a long-term growing process. Nothing fall out of the
>sky like a big
>surprise. YOU contributed to this process. YOU noticed all
>individual steps.
>So, please Pier, tell me what suddenly goes wrong?
>
>Regards, Thomas.
>
>
>
>> -----Original Message-----
>> From: Pier P. Fumagalli [SMTP:[EMAIL PROTECTED]]
>> Sent: Thursday, June 28, 2001 6:21 PM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED];
>> [EMAIL PROTECTED]
>> Subject: [JSR-96-Members] JSR-096 (Java Daemon API) critique...
>>
>> What is a daemon? Historically, a daemon has been defined by the CTSS
>> group
>> in 1963 as a "Disk And Execution MONitor", and has been
>adopted into the
>> Unix world as a program that is not invoked explicitly, but
>lies dormant
>> waiting for some condition(s) to occur.
>>
>> What are those conditions? Two classes, basically: an unspecified I/O
>> condition that triggers a stage of the daemon execution
>process, and a
>> service request; while we cannot schematize and abstract the
>first class
>> of
>> conditions, as these are dependant from daemon to daemon and
>determine
>> what
>> a daemon serves (the LPR daemon is different from the HTTP daemon),
>> history
>> already determined the second class of conditions as signals.
>>
>> For instance, it is assumed (and specified), that in
>response to a TERM
>> signal the daemon should terminate its operation and exit
>its process, in
>> response to a HANGUP signal it should hangup a connection, or more
>> recently
>> reload its configurations and restart.
>>
>> So, we can now abstract a more "generic" definition for
>daemon: a daemon
>> is
>> a dormant program (meaning detached from its parent process, and not
>> interrupting its flow of execution), which serves I/O
>requests for its
>> clients (from here the symmetry daemon=server) and interacts with the
>> underlying operating system with a defined set of signals or events.
>>
>> In the Win32 world, the term daemon is substituted with the term
>> "service",
>> and signals (which do not exist in that environment) have
>been changed
>> with
>> specific calls to certain declared functions, but on the overall the
>> design
>> remains the same.
>>
>> In any modern multi-user operating system there is a concept
>of "deamon",
>> "service", "server", and this concept has been associated
>with "a dormant
>> program serving I/O requests for its clients and interacting with the
>> underlying operating system with a defined set of signals or events"
>>
>> So far, the Java Platform lacked of a way to build an
>operating system
>> daemon using the Java language: Java applications are -all-
>interactive
>> programs, as the current invocation mechanism lacks of a way
>to create a
>> dormant program, and lacks of a way to interact with the underlying
>> operating system. Notably, see JavaSoft's Bug # 4323062: the java.exe
>> application invocator is used as a "deamon" and it fails.
>The current fix
>> is
>> a hack, and the platform still lacks of a way thru which an operating
>> system
>> daemon written in java can receive events triggered by the OS (we can
>> easily
>> launch "java myClass &" in Unix, but it dies inexorably when
>a TERM signal
>> is delivered to its process).
>>
>> Those are the problems I wanted to solve when I joined the
>JSR-096 expert
>> group, those are the issues that in the proposal listed on
>the JCP site we
>> are supposed to solve, and this is what the Java community
>expect us to
>> deliver.
>>
>> And today (incredible timing, I would say) I received the
>last copy of the
>> specification. And I'm disappointed to see that even in this
>last copy
>> there
>> is no reference to the behavior of the JVM process related to its
>> supporting
>> operating system. This specification does not solve my
>problem, is not the
>> reason why I joined this group.
>>
>> I see this version of the specification as a description on
>how to build
>> Java daemons for the Java Platform (one tier up), not a Java
>daemon for a
>> generic underlying operating system. This idea is
>corroborated by the fact
>> that its test Reference Implementation delivered with the
>specification is
>> based on JMX, doesn't touch at all the problems that we need
>to face when
>> integrating a generic Java daemon (from the definition
>above) within the
>> scope the underlying operating system. In my opinion, this
>specification
>> is
>> redundant, JMX and JSR-111 are already a great way to address these
>> problems
>> (I believe this came out also from our meeting in London last month).
>>
>> And that's why last week, on my own, silently, I came up with an
>> implementation that addresses the problems I needed to
>solve, and were
>> needed to be solved by my team (the Apache Tomcat team) to
>deal with how a
>> daemon written in Java can deal with the operating system.
>>
><http://www.apache.org/websrc/viewcvs.cgi/jakarta-tomcat-4.0/service/>
>>
>> Being responsible for solving these problems in the Tomcat world, his
>> implementation is what I feel I can safely deliver to my
>team and to the
>> community, while I don't feel that adding another layer of
>cumbersomeness
>> to
>> the current specifications will help in any possible way.
>>
>> And this is why as an Apache member, and its current
>representative in
>> this
>> expert group, as a Sun Microsystems employee working on the Tomcat
>> project,
>> I will not support the current specification until the
>problems I face,
>> the
>> problems I endorsed when joining this effort, the problems we were
>> supposed
>> to solve will be addressed.
>>
>> My implementation doesn't try to be a full 360 degrees
>solution to the
>> problems of daemons, and does not try to be a fancy JCP
>specification, but
>> it solves those problems that we, software developers, need to face
>> everyday
>> when developing daemons in the Java Language and with the help of the
>> community, will be improved and enhanced.
>>
>> I believe that this expert group went too far, forgetting
>its roots, and
>> the
>> real problems that we needed to solve.
>>
>> Also, another problem I faced while working with this group
>was the way in
>> which the discussion was held. Our mailing list rarely held technical
>> discussions, if not triggered by one of us in the Apache Software
>> Foundation
>> (thanks especially to Peter Donald) or few others and the whole
>> specification was developed internally at Dialogika. I've been thru
>> several
>> specifications in the Servlet/JSP and XML lands and being a
>member of the
>> expert group usually ment to know _what_ was going on, not
>just listening
>> to
>> decisions taken inside a company by few and "blessing" them.
>>
>> In your last email, Thomas, I quote "As a late reaction of
>Peter's critics
>> I
>> did some brainstorming and discussed the control code model
>once more with
>> my colleagues". WE, Thomas, are your colleagues on this
>specification, not
>> whoever works at Dialogika, my name is on that
>specification, and apart
>> from
>> the one in London I never had a brainstorming session with you.
>>
>> I'm sorry I didn't come to JavaONE, but my current economic situation
>> didn't
>> allow me to get there, I would have told you this in person,
>but I feel
>> left
>> out, and right now I should have to bless a specification
>that I don't
>> agree
>> with and that doesn't include any of my thoughts on the matter.
>>
>> Apart from this my vote on JSR-096 is a veto, a -1, for
>technical reasons,
>> we don't solve those problems we were supposed to.
>>
>> Sincerely,
>>
>> Pier Fumagalli
>> - Apache Software Foundation (member, JSR-096 representative)
>>
>> (CCing to the Tomcat Developers mailing list, the Apache JCP
>mailing list,
>> the Apache Members mailing list and my manager at Sun Microsystems)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
