Skip to content →

[GSoC 2018] First Collector, Core object implementation

Time flies away, gsoc 2018 phase one evaluation is close šŸ™‚ so, i speed thing up little bit and move to the coding in-addition to reading and learning part…

Previous post i was talking about how should data store, i was including a basic design of objects that will hold the information about calendar(s). While i start implementing, i realize that these objects will be use in any application or package which is related to the main storage service(cavabunga-server in that caseĀ  https://github.com/ITUBIDB/cavabunga-server). The best thing to do is separate these objects -and its factories (factory pattern applied)- to the other java package. (OK, i said will be working on a php-framework but i switch to java and i will explain later on this post)

The package that i create for that puspose is cavabunga-lib(https://github.com/ITUBIDB/cavabunga-lib) : Which includes:

  • Entity objects of parameters, components and properties.
  • Exception classes
  • Factory interfaces and implementations
  • And. http response wrappers.

With this way any service or implementation ,which uses cavabunga-server, is only need to include this package.
After i create the first release of cavabunga-lib i realize a bug and fix-it. So i use 1.0.1 version of the package (https://github.com/ITUBIDB/cavabunga-lib/releases/download/v1.0.1/cavabunga-lib.jar).

The server application also must have this package i create a new branch and made changes about separating the package. Basically cavabunga-server applicationĀ  has a maven dependency for cavabunga-lib.jar, i didnt upload the package to maven, so that package must include manually -for now- while compiling. And off-course this depenceny must add to pom.xml

After doing it, i started to implement first data collector for the project. I select one of the existing calendar (LWN.net which this source have mentioned in debian wiki page) for data source and implement data collector for it.

https://salsa.debian.org/dogukan-guest/cavabunga-collector-lwn-calendar

And i use cavabunga-lib package in the cavabunga-collector-lwn-calendar. The package is a Spring Boot application which provides restApi service. For parsing the data that collected from lwn.net, a http request have to be made to the application. There is two end points for application. -after cloning repo and running mvn clean install application will start via web server on localhost’s 8080 port, no ssl for now-

  • http://localhost:8080/json/YEAR/MONTH
  • http://localhost:8080/ics/YEAR/MONTH

First url will trigger the parser and collect the events from lwn calendar which are in that specific YEAR and MONTH ( for example /json/2018/07 will parse the date on the url of; https://lwn.net/Calendar/Monthly/2018-07/). After collecting data events and information about the events will be converted in the objects which included with cavabunga-lib package)

Second url will do the samething but it will convert all the data in to iCalendar format. Which known as common data type for storing calendar information.

But how theese iCalendar data is usefull? Because it is an common format, it supporting by almost every other calendar server. Like google calendar. After i get this data, i uploaded this ics file to google calendar and import the event. (there is import export option in settings section of Google Calendar). For the test: i take July 2018 calendar from lwn calendar and covert it to ics and import in Google Calendar with cavabunga-collector-lwn-calendar application.

In lwn calendar:

 

In Google Calendar

By the way, for the php thing: mapping objects to json output and working on it via php cost me alot of time so switch it but i will focus on it later.

In addition to that, i also made some changes on cavabunga-server(which was named cavabunga-core before) for seperation but cant made a merge. Problem is about the travis on github, as soon as figuring out i will merge cavabunga-server side -but has branch named cavabunga-lib-seperation which include all commits about seperation-.

Next things that i will do will include;

  • iCalendar to cavabunga-lib object parser (there are some direct *.ics feeds on internet)
  • implementing cavabunga-client for storing all theese objects to database and looking for a method for searching in this data.

writing a documentation for all building process (for;l cavabunga-server cavabunga-client cavabunga-lib and cavabunga-collector-*)

 

 

Published in GSoC 2018

Comments

Leave a Reply