[logback-dev] While you are working on FileAppenders... was: Question about a custom binary file appender.

[Joern Huxhorn]

First of all, sorry that I didn't reply earlier. I was pretty occupied.

I'm fine with Maartens Encoder suggestion.

I've done something similar in a different way, see http://sulky.huxhorn.de/projects/de.huxhorn.sulky.codec/apidocs/index.html
mainly because I need the amount of bytes before actually writing them  
but I could easily encapsulate my Encoder in the above interface.
I'm creating a byte[] because one entry consists of <Length of byte  
array as int><actual bytes>. This has the downside that it occupies  
more memory but can't be circumvented in my case.
I'd need the ability to write a header followed by an arbitrary number  
of the above structure, one for each event.
I'm not sure how header (needed) or footers (not needed in my case,  
and arguably a bit dangerous) would be implemented, yet.

Thanks for the discussion!

Regards,
Jörn.

On 02.08.2009, at 17:59, Ceki Gulcu wrote:

>
>
> Maarten Bosteels wrote:
>
>> I guess you forgot to rename the interface itself ;-)
>
> Yes, I did. :-)
>
>> From http://en.wikipedia.org/wiki/Encoder  "An encoder is a device,  
>> circuit, transducer, software program, algorithm or person that  
>> converts information from one format, or code to another..."
>> So I think calling it Encoder is appropriate, but I have no string  
>> feeling about the name of the interface.
>> The terminology also used in MINA: http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/codec/ProtocolEncoder.html
>
> If there is an established terminology for instance in Mina, than that
> should be taken into consideration.  However, being unfamiliar with
> Mina, I was a little surprised by the use of the term Encoder.
>
>> I have no idea how much work it is to support encoders in the  
>> logback.xml file.
>> I mean, we should be able to tell logback to use a XXXAppender with  
>> a ZZZEncoder ?
>
> If you can somehow reasonably express it in XML format, Joran can
> parse it, at least that's my experience so far. So, I would not worry
> about the parsing part and would concentrate on the "programmatic"  
> API.
>
>> Regards
>> Maarten
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework  
> for Java.
> http://logback.qos.ch
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev