- Bitcoin now accepted!
- Flattery will get you everything.
- Raising funds for Haiku through Goodsearch
- Debugger: Overview of New Features
- ASLR and DEP implemented
- Package Management: Building Things
- Package Management: The New Season Starts
- NFSv4 client finally merged
- Update 2: Contracts for Package Management
- Google Code-In 2012 Haiku Wrap Up Report
GSoC proposal : "Creating Services Kit core elements"
- Full name: Christophe Huriaux
- Preferred email address: c.huriaux _at_ gmail _dot_ com
- IRC / Trac username: Shisui
- Summer education: My classes ends on June, 18th, but the low load of work will allow me to begin my work for the GSoC.
- Employment: I'm not planning to take an other job if I am involved into GSoC.
- Schedule: I will be fully available for the whole summer, after my classes are completed.
- Time allocated: As GSoC would be my source of incomes for the summer, I will treat it as well, and allocate a full working week (35 hours in France) as a minimum to work on.
- Internet accessibility: I have an internet connexion at home.
- Previous years: It's the first year that I apply to the Summer of Code.
Who am I ?
Haiku is currently missing a subsystem allowing application to be connected to Web 2.0, although this is becoming important relatively to the interaction between users and "the world" through the Internet. The development of the Services Kit would permits to Haiku applications to access various web services, such as micro-blogging (twitter, ...), pasting services (pastebin, pastie, ...), social networks (last.fm, ...).
The Services Kit is based on various classes handling the low-level part of communication between applications and web services. Such classes would essentially implement the HTTP / HTTPS protocol which is used by almost all the web services, but also the FTP protocol to provide full access to data hosted on either FTP or HTTP servers.
On top of these classes, Services Kit would handle the messaging part of web services, through XML document parsing and creation, and JSON messages handling. Although some existing ports are available for these purposes (especially the XML parser, which is a huge task to achieve), it would be useful to have either a new DOM XML parser or a wrapper using existing and proven libraries, since handling XML messages used in most of the web services is not as complex as a fully featured XML parser (if we assume that messages sent by the remote website are well formed, there is no need for a syntax error detection and/or correction for example).
This project idea is focused on the core elements of the Services Kit in order to be fulfilled at the end of the GSoC program, further development would include, but should not be limited to, the creation of services classes implementing add-ons which provide the necessary methods to adapt the data transfer between the user and the web service. For example a BServicePaste service could expose a pastie add-on, a rafb one, etc. The fact is that if the base URL handling classes are well done, it will be pretty easy to extend the provided Services to websites which doesn't provide a web service (bulletin boards for example). The user should be able to select his Services preferences (prefered service, login and password when needed) within a preflet to let the applications use these preferences when possible, by interrogating a roster class of the Kit providing access to those preferences and to the list of available services.
I don't really know how much time it will take to achieve the main goals, if they are completed before the end of the summer I will continue my code development on the goals I have fixed for after the GSoC program (implementation of Services classes).
- Implement an HTTP requests class
- Basic handling of GET and POST requests
- URL encoding/decoding
- Hashes computing
- Basic cookie handling (optional for web services, but required for a full featured client-side URL Kit)
- HTTPS management (optional for now)
- Implement an FTP requests class
- Support for anonymous and login based connections
- Support for the most used FTP command : file download, file storage, directory list, ...
- Raw support for non handled commands
- Develop an XML API
- DOM API
- Document parsing
- Clean document generation
- XPath queries (useful to access a particular node when we know the document structure, like in web services).
- SAX API (optional, but required for a worthy XML Kit)
- Implement a JSON API
Additional goals for the project
- Provide the BService interface on which every Service class would be based on, a roster class should be able to give to application the list of exsiting services and add-on implementing them on the system.
- Implement some Services class examples
- BServicePaste, to share code snippets with other people.
- BServiceMessage, to send a message on a micro-blogging platform, or a social network, for example.
- Write proof applications (a replicant to send messages to Twitter for example)
This link (Google Documents) explain more precisely how I imagine the Services Kit API to be (draft, as of 04-28-2010).
I never had the opportunity to be involved into an open source project, so when a friend of mine told me about Haiku and GSoC a few months ago, I feel very enthusiastic about the possibility to participate in a OS project. Moreover, when I made some research on Haiku working and its API and Kits, I immediately found them useful and handy for the application developers, unlike others OS. I have been interested in communications and protocols since my very beginning in application development.
I made use of various web services (with cURL, in C and PHP) and I had the opportunity to write the server part of some of them for a former little IRC network. I also have experience in the implementation of the client-side HTTP requests through few related personal projects. If I'm accepted to work on this proposal, and finish it, I plan to further getting involved into Haiku kernel development since I'm very interested in OS theory.