<font><font face="verdana,sans-serif"><br></font></font><br><div class="gmail_quote">On Fri, Feb 24, 2012 at 6:51 AM, Sebastian Sauer <span dir="ltr"><<a href="mailto:mail@dipe.org" target="_blank">mail@dipe.org</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
    
  
  <div bgcolor="#ffffff" text="#000000"><div>
    On 02/23/2012 05:52 PM, Smit Patel wrote:
    <blockquote type="cite">
      
      <br>
      <div>On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer <span><<a href="mailto:mail@dipe.org" target="_blank">mail@dipe.org</a>></span>
        wrote:<br>
        <blockquote>
          <div>
            <div> On 02/23/2012 01:31 PM, Smit Patel wrote:
              <blockquote type="cite"> <span>Hi everyone,</span><br>
                <br>
                <span>I'd like to propose a </span><span>GSoC</span><span> project.

                  Here's the brief description about project idea.</span>
                <div> <span>Provide a dbus API that provides an generic
                    interface that can be used by external bibliography
                    engines (xbiblio, kbibtex, bibus)</span></div>
              </blockquote>
              <br>
            </div>
            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?</div>
        </blockquote>
        <div> </div>
        <div>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.</div>
      </div>
    </blockquote>
    <br>
    </div><span>I just had a quick look at xbiblio, kbibtex:and bibus</span>.
    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)?<br></div></blockquote><div>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] </div>



<div><br></div><div>[1]  <a href="http://community.kde.org/Calligra/Bibliography" target="_blank">http://community.kde.org/Calligra/Bibliography</a>  (strategy 2)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#ffffff" text="#000000">
    <br>
    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 <span>bibliography engines
    </span>like <span>xbiblio, kbibtex and bibus</span> into Calligra".</div></blockquote><div>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.</div>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div><br>
    <br>
    <blockquote type="cite">
      <div>
        <div>For other options I haven't try studying them in detail.
          We'll discuss about it on IRC.</div>
        <blockquote>
          <div>
            <div>
              <blockquote type="cite">
                <div> Calligra words doesn't have a good way to manage
                  references. These engines can manage references and
                  insert bibliography using interface provided. </div>
              </blockquote>
              <br>
            </div>
            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?</div>
        </blockquote>
        <div><br>
        </div>
        <div>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.</div>
      </div>
    </blockquote>
    <br></div>
    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.<br>
    <br>
    [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!<br>
    <br>
  </div>

</blockquote></div><br>