On 6/12/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Richard Wallace ha scritto:
> Stefano Bagnara wrote:
>>>> IMHO it is much better to start using the dnsjava objects for
>>>> encoding/decoding as a start also because it is much more stable than
>>>> the directory code.
>>>>
>>>> Stefano
>>>>
>>> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
>>> I don't think we need to go so far as to take all their base classes.
>>> One problem that I remember seeing with how they do their
>>> decoding/encoding is that it is actually a part of the message object,
>>> which does not seem like a good idea to me. One thing that appealed to
>>> me about the way Enrique did the base objects in protocol-dns is that
>>> the Message object and various record types are actually Value
>>> Objects. This makes a lot of sense. Once constructed they should
>>> never change.
>>>
>> I think this also applies to dnsjava objects: they ARE value object.
>> IMHO we can refactor them, we could also extract parsing into codec
>> classes but I still think that refactoring from dnsjava is much better
>> than starting from scratch.
>>
> Some of the dnsjava objects are Value Objects and some aren't. For
> instance, a Message object can be modified anytime during it's lifetime,
> but it looks like Records are Value Objects. But that's a minor detail
> that could be worked out. And refactoring is fun, so count me in if we
> can get consent.
I agree: refactoring is the best part if you have unit tests to prove
you did everything right ;-)
Message objects and codecs are generally trivial though they do
represent some work. I could help out with refactoring any messages
and codecs to new conventions and it sounds like Rich is, too. It
could go pretty quickly and it sounds like there are unit tests
available.
Also, we could start with dnsjava and slowly migrate to whatever our
thinking is about these objects, to prevent getting bogged down in a
bigger project.
The hard part is in the protocol workflow, be it on the client side or
the server side. Michael mentioned some use-cases for the server-side
and we'll have to keep that in mind but there are techniques for
making things flexible and extensible. A lot of what has been lacking
on Directory in this regard is feedback from users who drive us to add
extension points, remove deps, etc. In which case, it sounds like
getting this going at MINA and with a focus on a client will benefit
everyone.
Regarding client-side workflow, the use cases for Kerberos (my focus)
are similar to DNS in that it is a means to an end. You acquire
Kerberos credentials before accessing a subsequent service. I am
interested in what patterns emerge for handling multiple, disparate
protocol calls since I am in the middle of multi-protocol client work
on Directory these days. I haven't hit it yet, but now that I think
about it, I'll have the same problems in DNS that everyone on this
thread is having.
Enrique
