Let me present you the newest version of libsoylent: 0.4.0. Three weeks of hard work went into this release, and in fact so much was added and changed that we decided to skip a version-number. Sorry 0.3.0.
So, what’s in it? More or less a complete people-management-library. Our goal was to create a simple yet-powerful API that “just works”. Hopefully we managed that. If you have no clear picture of what libsoylent is or just want to know more about it, look at the examples we’ve put up on the libsoylent-page.
What comes next? Because the library is that new and fresh, much testing will be needed. If you want to help, just play around with libsoylent and report bugs that you may encounter to our mailinglist. Thanks! Besides, next to the need of more documentation and polishing, here is a list of features that will follow in the next releases:
- live-attributes (e.g. online-status)
- communication (launch applications for chat / mail etc.)
- address-book searching (atm you can only get all people)
- people association / merging
Please leave a comment on my blog if you have thoughts, ideas, criticism, feature-requests or suggestions for changing something. Just let us hear your opinion.
Anyway, if you’re working on something that needs people-functionality, why not give libsoylent a try?
Changes
- creating and modifying attributes works
- adding / removing attributes to / from people works
- attribute-mapping (for C runtime-types) implemented
- attribute-system (definition, cleanup and to-string functionality) implemented
- changes to people can be commited
- loading people from the addressbook implemented
- signals for SlBook, SlPerson and SlAttribute implemented
- integrated gtk-doc
- added a bunch of documentation
- added more tests
- added example-code (three examples)
- revised architecture
- a lot of internal-code improvements
- fixed a bunch of bugs
- added debugging functions
- a lot of polishing was done (code-cleanup, convinience functions and macros etc.)
Download
libsoylent is available for download at:
http://live.gnome.org/Soylent/libsoylent
Contact
Bugs, feature requests, questions and related discussion go to the Soylent mailinglist. You can join at:
http://lists.codethink.co.uk/cgi-bin/mailman/listinfo/soylent-devel
More
More information on libsoylent is available at:
http://live.gnome.org/Soylent/libsoylent
I just took a little look at the examples. It seems like libsoylent takes ownership of strings passed into it. That’s a pretty icky design and quite error prone from the developers POV. Its more usual to not take ownership of passed parameters.
Hi Rob. I won’t disagree
. I’ll describe the problem to show why I’ve chosen this design:
When a person is loaded from the addressbook, its attributes are loaded along with it (so you don’t have to make an IPC-call for every get_attribute). Most of the the attributes thus come from the addressbook, and must be freed again. Inserting static strings won’t be used very often, most applications will get their values from user-input and then insert them into a SlPerson. And mixing static strings and dynamic strings in a container (and thats what a SlPerson is somehow) is a bad idea. So I decided to use the same approach as GHashTable: libsoylent will be responsible to clean up for you, but a cleanup-function (GDestroyNotify) has to be provided. For string-attributes the default is g_free, but you may override it. I’ll post an example about the advanced attribute-system as soon as possible.
My question would be, do you have ideas for an alternative solution? I didn’t come up with anything else, but I’d be happy about a more convinient solution
Thanks for your input Rob!
See you
-Sven
I don’t see any po folder inside soylent svn folder
Translators love to see more and more applications with lots of strings to do
@Noya:
Well, I would just do the strdup myself within the SIPerson implementation. The argument that most strings aren’t static isn’t really valid, as most strings will already have a defined lifetime and will need to be dupped to be put in the SIPerson anyhow.
I guess you’re optimising for the case of getting a string from a GtkTextBuffer, but really, is this a necessary optimisation? Is an application going to be creating 1000′s of SIPersons a second from a UI? /me guesses not…
This way you’re code is simpler as all your strings are allocated by your code and have a lifecycle defined by your code, and strange things that developers do won’t break it. (like passing in a string that gets freed when their obejct is destroyed or somesuch).
You badly need to write reference documentation. The stuff that’s online is just empty (or sometimes worse) default stuff generated from gtk-doc, as far as I can tell.
The process of documenting what functions do is a large part of testing that the functions act sensibly and do useful things.
I’d love to review the API once you have done that.
@Gil:
. At the moment libsoylent has not text-output at all (except some debug-output). I guess you want to see i18n support in Soylent, the application itself. And be sure, you’ll get i18n support in Soylent, Travis is working on that.
Hi Again
@Rob:
I could strdup all strings inside the libsoylent code, perhaps this would be the better solution. I just see a problem with consistency here: You can put arbitrary structs into a SlPerson (see the SlAddress or GDate in the example). libsoylent also has to care about freeing those structs and can’t duplicate them (as it doesn’t know what’s behind the gpointer). Do you think it’s okay to duplicate strings, but not the structs?
Clearly, creating, deleting and modifying people isn’t that performance-critical since it won’t be done 1000 times / sec. A strdup inside would be no problem from that POV I guess.
@Murray:
Good point. I just noticed that I’ve forgotten to adjust the chapters of the documentation to the documented API, so some documented functions and methods are not included atm. I will fix this in SVN. Over the course of this week I’ll focus on writing more documentation.