GSoC2015 Proposal: syslog ng for Java (Garmine)
While syslog-ng is already extensible it can mostly be done using the C language. Although C is a great language it is probably not the best idea for the implementation of every feature.
The goal of this project is to make it possible to write filters, parsers, rewrite rules, template functions, and even sources using languages running on the JVM by implementing JNI connections in the pipeline.
Developing a well documented JNI for syslog-ng would not only mean easy development of Java modules but even giving full access to anything that is able to run on a JVM (including not only Java but even other languages such as Scala, Clojure, ...) and the possibility to use libraries written for these languages while developing internals.
By providing easy access to many new (managed) languages not only easy tasks and plugins could be written faster but the higher number of choices can potentially increase the number of contributors and modules for syslog-ng.
Easier Java connectivity also has the benefit of attracting enterprise users as large systems written in Java aren't uncommon and thus syslog-ng can become an even more viable logging solution for such projects.
All in all more languages mean more people and more possibilities which sounds like something potentially great.
By developing such a high volume interopaility project I would get a chance to deepen my knowledge of C, and JNI and most importantly by the end of the summer I would have a deep understanding of syslog-ng making usage and future contributions much more easier.
Combining my knowledge of the two popular languages will most likely become a valuable skill that will help me in the future for both personal projects and work opportunities and open the possibility to contribute to other open source projects such as LWJGL.
Although what I find the most exciting is that I may finally write code that will be used by many people worldwide, contributing back to the community which taught me programming.
- Full Java support:
- Destinations
- Filters
- Rewrite rules
- Template functions
- Parsers
- Sources
- The Java hierarchy should mimic the original C code's hierarchy
- Project must compile via command line tools
- Documentation
- Plain old text for usage of every feature
- Java examples for every feature
- Unit tests
Although the original idea only mentions Java (and possible JVM connectivity hidden somewhere) the JNI interface required for the Java language should be able to support most (every?) language running on the Java Virtual Machine.
I'll focus on following the original goal i.e. Java connectivity but as I don't see a reason why it shouldn't be easily achievable I'll keep on eye on other JVM languages as well. And if time permits even write examples in another one of them.
Please note that I plan on writing tests, examples and documentation in parallel with (or immediately after) implementing connections, so the schedule may not state these activities explicitly.
(Elements in the same interval do not represent any planned order of completion or importance)
-
March 16-29
- Getting familiar with syslog-ng code and the build system
- Finding and fixing development issues on dev system (which is Arch Linux)
- Think, write and apply a lot
(Present at the time of writing this schedule.)
-
March 30 - April 26
- Get used to using the mailing list
- Study syslog-ng pipeline and it's components in depth
- Examine existing proxies
- Examine&extend existing Java destination
- Research JNI and the possibility to include other JVM languages
-
April 27 - May 3
- (Refine summer plans)
- Finalize destination connectivity
- Tests, docs, etc. for destination
-
May 4 - May 29
- Template connectivity
- I already have some experience regarding this code
- Used by Pipes, probably a logical place to start with
May 25: GSoC coding officially begins
May 26: exam period at BUTE starts, potentially more time for development (~20 hrs weekly)
-
May 30 - June 22
- Filter connectivity
- Seems to be straightforward
- The first stop of a message after exiting a Source
June 22: exam period at BUTE ends, large amount of time for development (40 or more hrs weekly)
-
June 22 - July 8
- Parser connectivity
- I love writing parsers so it should be refreshing and motivational to work on it midtime
- 2nd stop of the message
-
July 9 - July 24
- Rewrite rules
- Might be more logical to implement directly after filter
-
July 25 - August 9
- Source connectivity
- Seems to be the simplest and most straightforward
- Leaves room to correct delays introduced in previous steps
- Should be relaxing (famous last words)
-
August 10-21
- Final polishing (aka buffer weeks)
- Performance tests and benchmarks
- Stretch goals in case of finishing early:
- additional examples in another JVM language (probably Scala or Jython)
- re-implement an existing module in a JVM language as a more complex example & proof
I don't plan on being away for more than 1-2 days occasionally this summer and while I'll likely work on other issues I already find this project exciting and challenging enough to guarantee that I'll spend most of my time completing (maybe even exceeding) the target functionality in the original idea.
I started coding coding around 6 years ago, first using Java and later extending my knowledge to many other languages including C, Python, FORTH, Active Oberon and Bash just to name a few of many. Right now I'm an undergraduate at Budapest University of Technology.
So far I wrote OpenGL&CL experiments, an overly complicated BrainF#@k interpreter and contributed to a game called ScrumbleShip in C. I also developed a primitive web browser resembling the Line Mode Browser from scratch using an own HTML parser, a JSON parser, contributed to a Minecraft server's code and wrote many other smaller and larger programs in Java. Due to my interest in OpenGL I also gathered knowledge about JNI.