> > Well, it doesn't matter to much. In my mind, the idea is to design codec, > and then project can decide to use them, or not. But for those who start a > new project using one of the existing codec (for instance, we see many > people wanting to write a XMPP server), then it can help them. The very same > thing for HTTP. > > Now, I don't want to strip codecs out of asyncweb, or ADS. It's just the > people from the project to decide whether they want to use the available > codec, or not. A big mistake was done with Asyncweb I think, and we should > not repeat the same pattern...
Let me explain what I meant inheriting from ApacheDS (an example). Rather than reinventing the wheel, and write things from scratch, we could reuse the logic/POJO's. As such getting everything from ApacheDS won't be possible as the code is organized differently. As I see ApacheDS project may not be a consumer as of now, but at the same time there may be users who are building something similar. It could be a value add. Let's just remove the word codec for a while. Now all frameworks who use Networking, have translators from byte[] - object and vice-versa. We just need to give them codec decorator's. This gives us two approaches 1. Write complete decoding/encoding by ourselves 2. Use any existing library to actually do transformation, within the codecs This can be decided on a case to case basis. I wanted to write decoder's for SMPP. There was quite an overhead to create POJO's all over again. So I decided to reuse jsmpp lib (option# 2). I am yet to fork out MINA branch for the project. >> I think as soon we redo the codec architecture for use only streams & >> ByteBuffer, we can restart the debate :) >> > > yup. I just want to drop ideas while they are still in my head... This is reason why I trouble Dev community a lot. The ideas are safe here :-)
