Re: Disable the app subproject (temporarily)?

Dear All,

As a follow-up to Petr’s post I’d like to express my vision of Calitko. I’ll be looking forward to reading your views on our common aim and the way to achieving it. I would appreciate any feedback and ideas how to better communicate the message and aim of Caltiko Project on our own and other sites.

The ultimate aim of Calitko Project is to create an extensible software P2P platform. Calitko is both a framework and the application we build while developing the framework. The idea is not to include Calitko as a library to other projects, the idea for other projects to build upon Calitko. A suitable example I think is Eclipse. Calitko would provide core services which 3rdParty plugins could build upon to extend Calitko and provide new services.

Calitko would be of interest to developers fond of software technologies, which care about creating high quality software at all levels (down from source code up to the UI). It would be of interest to P2P researchers, who would be able to easily experiment with existing and new protocols because most of the tasks would already be handled by Calitko (for example, we already have packet-gen which allows us to describe packets in XML and have the C++ code generated).

The architecture of Calitko Project is quite simple - we have three layers of abstraction - Protocols, Services, UIs. We are currently doing work exclusively at the lowest layer (Protocols). If at the Protocols level we have the file-transfer and file-sharing protocols HTTP, FTP, Gnutella, BitTorrent, we could have a single FileDownloader service at the Services layer. Ideally, once we have the FileDownloader service we would be able to extend it to support infinite number of new protocols without many modifications to FileDownloader itself. Similarly, we could create a new service at the Services layer that uses HTTP or Gnutella for something different than file transfers, e.g. for media streaming. At the UIs layer we could have alternative UIs for each of our services.

I see the best way to proceed is bottom-up, i.e. from Protocols through Services to UIs. First we would concentrate on file transfers (both downloads and uploads), next we could move to instant messaging or distributed computations. Once we have a solid base of code and services and more and more new people join us, we would have an infinite set of possibilities - that’s what I love about software most - aside from CPU and memory, which are increasing steadily, the only limitation we have with software is our own imagination!

Best regards,

Peter

Would you like to post a relpy?


This post is a reply to:
Re: Disable the app subproject (temporarily)?
Hi Peter, I agree with you that we should disable the calitko.pri subproject since we're not working on it. However, I think that we should at first focus on some protocol (more...)

Follow-ups:
Re: Disable the app subproject (temporarily)?
Dear all, I'm planning on further developing the Http component. I will target the functionality of downloading a complete file with a single HTTP request. It will be interesting to see (more...)