[haiku] Re: [GSoC] Services Kit
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 07 Apr 2010 12:35:57 +0200
On 2010-04-07 at 12:13:29 [+0200], Christophe Huriaux <c.huriaux@xxxxxxxxx>
wrote:
> I would like to have some reviews on the goals of my proposal if
> possible. The following points are those I think I can complete within
> the allowed time. The tasks marked as "optional" are those I can begin
> before the end of GSoC if the others are completed, or after GSoC
> otherwise.
>
> * Web core of Services Kit
> + HTTP library
> - Handling basic GET/POST requests on HTTP 1.0/1.1 servers
> (with or without chunk encoding)
> - Functions to URL encode/decode data
> - MD5/SHA1 hashes computing
> - Giving developer the possibility of modifying every part of
> the request
> - Basic cookie manager (optional)
> - Using HTTPS if available (optional)
> + FTP library
> - Accessing FTP servers with anonymous or login based connection
> - Shortcuts functions for basic commands (RETR, STOR, MKD,
> RMD, RNTO, DELE, LIST)
> - Possibility to use raw commands for non-integrated ones
>
> * Data interchange formats kits
> + XML parser
> - Developing the XML DOM and/or SAX parser
> - Handling XPath requests (for DOM) (optional, but pretty
> useful in order to use webservices)
> + XML document formatter
> - Ability to generate a clean XML document
> + JSON parser / formatter (optional)
> - Extracting data from a JSON request
> - Forging a JSON request from developer data
>
> * Services classes development
> - Development of various services class such as pastewall
> services, last.fm, twitter, ...
Sounds good to me.
> The web core and XML / JSON Kits are the very base of Services Kit as
> they provides the most basic functionalities to be offered to
> applications making use of web services.
>
> I'm still thinking of how to handle the asynchronous I/O of the web
> network core in order to make the http/ftp requests as easier as
> possible for the final developer.. QT has the signals/slots system,
> but how about Haiku ?
Haiku has the Application Kit, which contains BHandler and BLooper as well
as BMessage and BMessenger. The signal and slot system is nice as long as
you deal with single threaded applications. With multi-threaded apps, you
quickly get headaches. BMessage based notifications are very ingrained into
the Haiku API, and should be used here as well, IMHO. For example, if you
have an asynchronous API function:
???::SendRequestAsync(???, const BMessenger& replyMessenger);
You can store the BMessenger and send it a BMessage with a defined
protocol, i.e. "defined" == a documentation about what fields will be in
the message, and what the message "what" constant will be. An example of
this technique is the Haiku node monitoring. It requires writing more code
than with signals and slots, but it is more flexible in some regard, like
you can extend the fields in the message at a later point without breaking
existing clients. And of course you won't run into any threading issues,
since BMessengers are thread-safe. (Even if the target is already gone.)
Another good design, because it's very clear how it works, is the use of
hook methods. This requires understanding of locking requirements by the
client code, though. Hook methods are essentially the same thing as signals
and slots, only they require knowing the target on which to call the hook
method and are of course more verbose to program and setup.
BHandlers also implement the listener/observer pattern via the
SendNotices() methods. This may also be an interesting option, since this
framework allows to connect multiple observers to a single BHandler, and
allows the selection of events that the observer is interested in. The
BeBook has a lot of documentation on all this:
<http://www.haiku-os.org/legacy-docs/bebook/BHandler_Overview.html>
<http://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Messaging.html>
> Moreover, a DOM XML parser is a fairly huge task and I can't find any
> informations on a existing Haiku port of a XML library, it would take
> a lot of the GSoC time, that's why I'm not sure of the exact timeline
> of this proposal. To be fully completed, Services Kit would require a
> little more time than summer, but I'm planning to be involved into
> Haiku project even after GSoC end if I have the opportunity to work on
> this proposal.
A port of Xerces-C appeared on <http://www.haikuware.com> not long ago.
Some people have done ports of Xerces over the years, among them Ingo
Weinhold, and we used this port in eXposer and other YellowBites
applications. From this experience we know that some effort went into the
port to make it truely work fine. Maybe Xerces has become more portable and
the current port works as expected. We have wrapped Xerces within our own
API, it's certainly doable. Maybe some of this can be re-used, but it needs
updating to the current Xerces API. libxml2 has also been ported and should
be available via <http://ports.haiku-files.org>. I cannot comment whether
this port works as good as on other platforms, and whether it fulfills all
your requirements.
Best regards,
-Stephan
Other related posts:
