I'm not giving up, and I want to argue some more 8-]. >From a pure Axis context perspective, I agree (without having looked through the code in detail) that your assertion about there not being any private state is correct. From the perspective of the state as a whole, I don't agree -- in our use of Axis2, for example, we have properties stored in the contexts that have private state information that must be serialized.
I'm not arguing with the fact that we COULD place the serialization code outside of the objects that they operate on -- that can always be done (although it may require exposing an interface only used by the serialization mechanism if there is private info) -- I'm arguing about whether or not it SHOULD be done. By moving it outside of the objects themselves, you are duplicating the "metadata" of the object structure and hierarchy and therefore any changes to that "metadata" (e.g. adding a new field, changing types, moving fields, etc.) need to be made both to the class and to logic external to the class. I believe this to be error-prone and a bad design. Maybe your are correct in believing that the serialization code can only be used by RM -- even so, I believe that RM is important enough that the core should make allowances for it and that this particular allowance makes for a more maintainable system if nothing else. -Bill On Fri, 2007-01-05 at 23:19 +0530, Sanjiva Weerawarana wrote: > On Tue, 2007-01-02 at 15:28 -0800, Bill Nagy wrote: > > OK, here's my $0.02: > > > > (1)I would argue that reliable delivery of messages is an integral part > > of a web services stack and therefore deserves special treatment in the > > core where necessary so long as it does not adversely affect processing > > when the reliability is achieved through other means (such as being > > inherent with a transport) or is not required. I believe that exposing > > a serialization/deserialization API as part of the MessageContext API is > > a part of this. If this API can't be used by other things, then we > > should try to make it better (See (3) below.) > > I think we're in agreement that there's no private state involved with > this serialization- so there's no fundamental reason for this code to be > inside MC instead of outside. > > > (2)I will also argue that, following good design practices (e.g. > > encapsulation,) objects themselves should be in charge of > > persisting/restoring their state. > > The problem is that we've changed the conversation from the right > solution to the problem to having a solution which needs a problem. The > problem is one of supporting saving state for RM and we both appear to > agree that technically this can be outside of MC stuff. The solution > that is in front of is much more generic (saving an MC), yet the current > impl is not so generic and really cannot be made to be generic. (That's > my conclusion after thinking about this for more than an year .. > remember we've been here done this before; these objects were > serializable a while back and we backtracked. YMMV obviously. > > > Does this increase the amount of code > > within the objects? Sure. Does it make the objects harder for others > > to understand? Doubtful -- most of the relevant code is kept within a > > few methods. Does it make modifications to the object more convenient > > and less error prone? Certainly -- having all of the code in once place > > is much easier, although it still requires some degree of vigilance. > > It's far better to have each object delegate the tasks of serializing to > > each of its subordinate objects (i.e. fields) than to have a single > > block of code that understands how to serialize the entire graph -- > > something which may be impossible if some of the properties stored > > within the contexts are well encapsulated. > > Except that in this case none of the things Ann is saving are private > members. I would not agree that that means things are not "well > encapsulated"- it means that interesting bits of the various contexts > are public properties. > > > (3)This is iterative development -- lets be real, there are a lot of > > things in Axis2 that don't work quite the way that one would think. I > > don't believe that anything should be held out simply because it doesn't > > address every possible usecase, so long as it doesn't break the rest of > > the system. > > Sure. If you do know of other areas that need improvement please do open > JIRAs so that we can keep track of them. > > > While Ann's patch is undoubtedly not perfect and will continue to > > evolve, I do believe that it is a step in the right direction and should > > be committed. > > I don't agree its the right way to solve the problem but I'm giving up > and lifting the objection because this conversation has become > unnecessarily politicized. Disappointing but let's get on with it and > move onto bigger and better problems we have to deal with! > > Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
