GSoC idea

[Smit Patel]

On Fri, Feb 24, 2012 at 6:51 AM, Sebastian Sauer <mail at dipe.org> wrote:

> **
> On 02/23/2012 05:52 PM, Smit Patel wrote:
>
>
> On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer <mail at dipe.org> wrote:
>
>  On 02/23/2012 01:31 PM, Smit Patel wrote:
>
> Hi everyone,
>
> I'd like to propose a GSoC project. Here's the brief description about
> project idea.
> Provide a dbus API that provides an generic interface that can be used by
> external bibliography engines (xbiblio, kbibtex, bibus)
>
>
>  dbus is optional[1] and so would be everything that depends on it. So,
> why dbus? Why not just a plugin? If it should be in another process
> (stability, long-running things, shared among Words-processes, etc) then
> why not for example QLocalServer?
>
>
> If dbus is not available for windows and OSX then we can rule that out. We
> can consider what bibliography engines like bibus, kbibtex etc are using
> for the same thing with LO and MS Office.
>
>
> I just had a quick look at xbiblio, kbibtex:and bibus. Am I right that
> none of them comes with a dbus daemon? So, I seriously ask myself why you
> like to drag dbus in? Why not just do it the same way it's done in e.g.
> Kile (I assume linking against a lib)?
>
I haven't looked at these technologies for whether or not to choose them.
So I'll look at them and we'll discuss it at length once my exam gets over.
It just occurred to me first when i thought of an interface providing rpc
api to these bibliography engines. [1]

[1]  http://community.kde.org/Calligra/Bibliography  (strategy 2)

>
> I just bring up the topic cause your proposal explicit names dbus but does
> not name a reason why and for what. So, I suggest to either make very clear
> in your proposal for what and why you will use dbus XOR change the proposal
> do not make that given but turn it into something you need to
> investigate/research during the gsoc-time to see if that's the best
> approach. So, something like "investigate and research technology-choices
> to integrate bibliography engines like xbiblio, kbibtex and bibus into
> Calligra".
>
Yes. I'll investigate/research on these technology-choices and I wont
mentioned dbus explicitly until it gets clear to me about what to choose
and why.

>
>
>  For other options I haven't try studying them in detail. We'll discuss
> about it on IRC.
>
>   Calligra words doesn't have a good way to manage references. These
> engines can manage references and insert bibliography using interface
> provided.
>
>
>  Guess there would be quit some work needed in core-code to make it proper
> update references on loading/saving/editing. Does what ODF specifies cover
> what you propose? If yes then it should maybe not be optional and no be
> available for so many platforms[1]. If not then how to you plan to keep
> interoperability? I think your proposal includes loading/saving?
>
>
>  Yes. I need to change some core-code but bibliography engine is in
> place. So it won't be a big problem. I think the confusion is because I
> haven't merged my branch words-references-bibliography-smit with master. My
> branch has all the changes done so far for bibliography support.
>
>
> Ah, good to know[1] :) I would definitively add to your proposal
> references of the work you did already. Its a *huge* advantage your
> proposal has over all other proposals that you already did some of the
> work. So, imho your proposal should include some words what you have
> already and how exactly you like to spend the gsoc-time to improve that.
>
> [1] Well, I did know you worked on that topic before but have no clue in
> what state that work is. Means what is done and what you like to do during
> the gsoc-time. But yes, that's maybe a bit to much input for a first "gsoc
> idea" mail but more material for the final proposal. In any case lot of
> thanks for hacking on that important topic!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120225/ea4f43f6/attachment.htm>