[be] [ bibledit-Feature Requests-1898061 ] focus sharing with WeSay

[SourceForge.net]

Feature Requests item #1898061, was opened at 2008-02-20 19:42
Message generated for change (Settings changed) made by teus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=658624&aid=1898061&group_id=111189

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Teus Benschop (teus)
Assigned to: Nobody/Anonymous (nobody)
Summary: focus sharing with WeSay

Initial Comment:
Work has been done to allow focus sharing between WeSay and other software like 
OurWord and the Fieldworks/Translation Editor.
Are there any plans for this also between Bibledit and WeSay?

Wolfgang 

----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-21 12:23

Message:
Logged In: YES 
user_id=890881
Originator: YES

Just a quick follow-up to say that I looked at two C++ xml-rpc libraries,
and XmlRpc++ looked much nicer to use (example client code here and here).
Also, it's based on a Python library (py-xmlrpc) so C++ and Python client
code would look pretty similar, which is helpful, I think. XmlRpc++ is a
package on Ubuntu, but it also claims to build easily on Windows; I was
also able to build the library and run the test clients on Mac.

Thanks for the clarification about your-d-bus comments, John. The original
para didn't mention d-bus, and although I could see that a word was
omitted, I guessed wrongly about what it might be! :-)

--Neil

http://xmlrpcpp.sourceforge.net/
http://xmlrpcpp.sourceforge.net/faq.html
http://xmlrpcpp.cvs.sourceforge.net/xmlrpcpp/xmlrpc%2B%2B/test/HelloClient.cpp?revision=1.8&view=markup
http://py-xmlrpc.sourceforge.net/


----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-21 06:26

Message:
Logged In: YES 
user_id=890881
Originator: YES

Hi Neil,

 

Thanks for your email.  My colleague here Cambell is a
communication-protocol wiz… too bad my initial Dictionary Services work
was done during Christmas break when he wasn’t around.

 

Yes, it now looks like I should just switch to use XML-RPC.net  using
“.net remoting” (rather than IIS, shudder), and drop WCF altogether.

 

>>If I recall correctly is not design to supply things over a LAN, so
that’d be a drag.


>Not sure what you mean here. Surely all these mechanisms (including
xml-rpc, d-bus) use sockets underneath the hood? Just local ones, rather
than TCP/IP ones. Also, HTTP doesn't necessarily imply TCP/IP. It's an
application-level protocol than can be used over any transport mechanism. I
don't see why you'd want to do dictionary-to-editor synchronization between
machines, but if you did, wouldn't a LAN be the only way to do it?

What I meant was, (and I’ve now verified from Wikipedia), that dbus is
for communication between processes *on a single machine*.  Our most likely
scenario is where a small team of mtts in an office, with both dictionary
and translation going on, could use version control to make use of each
other’s work.  However, it would be nice to not close the door on the
scenario where one member would like to look up data from another
person’s work, in a more real-time way (if supporting that didn’t cost
more).  The XML-RPC over TCP-IP or http leaves that door open.

 

 

>>What I had originally hoped for is to get some kind of tcp-based xml-rpc
going. This would work on the machine and between machines. What is needed
I think is someone to get a simple proof-of-concept working, on multiple
platforms, from at least .net and one other language platform (e.g. C or
python). This would be an easy to describe and fun volunteer project.


>I'll see if I can find anyone, and let you know if I do.

Thanks.  It would probably just take me a day or two to refit WeSay and
the .net client library (which will make all this invisible to TE, OurWord
and Paratext 7.1).  Then someone else could make demonstration projects of
clients consuming from C and Python.


>Where do we find your message specification?

For xml-rpc, I’m not clear how one defines a spec(there does not appear
to be an equivalent is of SOAP’s WSDL).  I saw this from the implementer
of xml-rpc.net:

 

“The very informal API specs that XML-RPC seems to attract are often
wrong, or misunderstood so that the server implement something
different…”

 

Ah well. Right now, the spec is just  .net interface:

 

using System.ServiceModel;

 

namespace Palaso.Services.Dictionary

{

    [ServiceContract]

    public interface IDictionaryService

    {

        /// <summary>

        /// Search the dictionary for an ordered list of entries that may
be what the user is looking for.

        /// </summary>

        /// <param name="writingSystemId"></param>

        /// <param name="form">The form to search on.  May be used to
match on lexeme form, citation form, variants, etc.,

        /// depending on how the implementing dictionary services
application.</param>

        /// <param name="method">Controls how matching should
happen</param>

        /// <param name="ids">The ids of the returned elements, for use in
other calls.</param>

        /// <param name="forms">The headwords of the matched
elements.</param>

        [OperationContract]

        void GetMatchingEntries(string writingSystemId, string form,
FindMethods method, out string[] ids, out string[] forms);

       

        /// <summary>

        /// Get an HTML representation of one or more entries.

        /// </summary>

        /// <remarks>I had originally planned this to just be a fragment,
which is more composable,

        /// but that then left us with the problem of where to get the
style definitions, if we

        /// don't have an html header.</remarks>

        /// <param name="entryIds"></param>

        /// <returns></returns>

        [OperationContract]

        string GetHtmlForEntries(string[] entryIds);

 

        /// <summary>

        /// Used to help the dictionary service app know when to quit

        /// </summary>

        /// <param name="clientProcessId"></param>

        [OperationContract]

        void RegisterClient(int clientProcessId);

 

        /// <summary>

        /// Used to help the dictionary service app know when to quit

        /// </summary>

        /// <param name="clientProcessId"></param>

        [OperationContract]

        void DeregisterClient(int clientProcessId);            

       

        /// <summary>

        /// Cause a gui application to come to the front, focussed on this
entry, read to edit

        /// </summary>

        /// <param name="entryId"></param>

        [OperationContract]

        void JumpToEntry(string entryId);

 

        /// <summary>

        /// Add a new entry to the lexicon

        /// </summary>

        /// <returns>the id that was assigned to the new entry</returns>

        [OperationContract]

        string AddEntry(string lexemeFormWritingSystemId, string
lexemeForm,

                        string definitionWritingSystemId, string
definition,

                        string exampleWritingSystemId, string example);

 

        /// <summary>

        /// this is useful for unit tests, to see if the app went where we
asked

        /// </summary>

        /// <returns></returns>

        [OperationContract]

        string GetCurrentUrl();

 

        [OperationContract]

        void ShowUIWithUrl(string url);

 

        /// <summary>

        /// mostly for unit testing

        /// </summary>

        [OperationContract]

        bool IsInServerMode();

 

 

//todo        void AddInflectionalVariant(string writingSystemId, string
variant);

 

    }

 

    public enum FindMethods

    {

        Exact,

        DefaultApproximate

    }

}

----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-21 06:25

Message:
Logged In: YES 
user_id=890881
Originator: YES

 Hi John,

On 2/20/08 7:03 PM, John Hatton wrote:

> The result should be that we can use a standards-based protocol, like
XML-RPC, and then any of these other platforms can “play”... If you can
come up with a non-WCF approach that is some subset of these, let me know!

It looks like there are plenty of libraries for XML-RPC in various
languages, including .Net, so maybe that would work. (The .Net one would be
for Mono on Linux, if Mono's WCF doesn't mature soon enough.)

The Wikipedia article on xml-rpc has some good links, including a fairly
stable and well-used one for C++ (mainly aimed at Unix systems, but it does
also work on Windows).

> I also did some experiments with DBUS; there is a .net client for it
(from ndesk), but I didn’t figure out how to run, um, the “bus”
itself on windows.

Yes, the problem with DBUS is that it isn't peer-to-peer, rather a star
topology (as I understand it) requiring a background process to be running.
In some ways, that might be what you want for some use cases (eg several
Bible-oriented programs all scrolling together) but I like the idea of a
simple, paired approach.

> If I recall correctly is not design to supply things over a LAN, so
that’d be a drag.

Not sure what you mean here. Surely all these mechanisms (including
xml-rpc, d-bus) use sockets underneath the hood? Just local ones, rather
than TCP/IP ones. Also, HTTP doesn't necessarily imply TCP/IP. It's an
application-level protocol than can be used over any transport mechanism. I
don't see why you'd want to do dictionary-to-editor synchronization between
machines, but if you did, wouldn't a LAN be the only way to do it?

> What I had originally hoped for is to get some kind of tcp-based xml-rpc
going. This would work on the machine and between machines. What is needed
I think is someone to get a simple proof-of-concept working, on multiple
platforms, from at least .net and one other language platform (e.g. C or
python). This would be an easy to describe and fun volunteer project.

I'll see if I can find anyone, and let you know if I do.

Where do we find your message specification?

--Neil


----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-21 06:24

Message:
Logged In: YES 
user_id=890881
Originator: YES

Hi guys,

“Dictionary Services” is still an alpha-quality thing, not something
you want to spend time on yet.  Even WeSay is still on the road to shipping
on Linux.

 

However, I would be very happy to have help figuring out how the
communication should happen.

 

>From an email to John Thomson yesterday (they want to provide these
services from FLEx, and consume them in TE) (Teus “WCF” is a Windows
Communication Library, which is one of the 3 libraries that constitute .net
3):

 

 

So, why did I choose WCF?  Partly for good reasons, partly for mistaken
ones.  The mistaken one was that I thought (and even tested, but just
fooled myself) that mono had implemented the part of WCF I needed to use.
In fact, it only has HTTP communication at this time.

 

The good reason still stands.  I actually would like to have a standard
that doesn’t require .net at all.  I want python/c/java whatever to
provide or consume these services.  And WCF is terrific in that it allows
you to trivially switch the actual protocol being used without changing any
other code.  Combine this with how I did the interface, which is to only
use simple values, like strings and integers (no .net classes).  The result
should be that we can use a standards-based protocol, like XML-RPC, and
then any of these other platforms can “play”.  Make another protocol
tweak, and now the Lexicon editor app can server up dictionary services
across a LAN or even the web.  If you can come up with a non-WCF approach
that is some subset of these, let me know!  The next best thing I know of
is to use command-line apps as the communication mechanism.  I.e., some
form of the old .net Remoting for .net apps, then a .net command line tool
for requests from non-.net apps.  So the non .net app says “exec
GetDefinition foobar” and gets back some html.

 

Ok, so you see the state we’re in.  We have a pretty slick .net/windows
system going.  But WCF didn’t actually pan out for linux.  Maybe someday.
 I also did some experiments with DBUS; there is a .net client for it (from
ndesk), but I didn’t figure out how to run, um, the “bus” itself on
windows.  It too is a difficult to use, limited-capability thing compared
to WCF (which is easy and powerful), but if that’s what it took, and if
we had a good story to tell on the windows side, we could switch to that. 
It if I recall correctly is not design to supply things over a LAN, so
that’d be a drag.  I also wouldn’t rule out different methods for each
platform.

 

What I had originally hoped for is to get some kind of tcp-based xml-rpc
going.  This would work on the machine and between machines. What is needed
I think is someone to get a simple proof-of-concept working, on multiple
platforms, from at least .net and one other language platform (e.g. C or
python).  This would be an easy to describe and fun volunteer project.

 

JH

 

----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-21 06:21

Message:
Logged In: YES 
user_id=890881
Originator: YES

I'm sure you would be able to find it somewhere in the WeSay Subversion
repository, probably under Palaso. But they only have code for .Net, so for
Bibledit you would probably want to develop something equivalent in C++
using an xml-rpc library.

You could of course run a modified version of the sample activity in a
sub-process, and communicate with that, but I'm concerned about the
resource costs on a machine like the XO of all the sub-processes that BE is
already running, without adding any new ones. See "Developer Issues" from
the OLPC wiki, which says, for example, "developers [need] to pay much more
attention to the memory 'footprint' of applications."

http://www.wesay.org/code/

http://wiki.laptop.org/go/Developers/Issues


----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-02-20 19:43

Message:
Logged In: YES 
user_id=890881
Originator: YES

It's a wonderful feature to be able to jump from the translation project
into the dictionary; I do it all the time between PT and Toolbox (though I
think that jump hangs up with certain Unicode characters, unfortunately).
You can add examples from Scripture to a dic entry or edit a definition, or
look up a word while writing back translation, or add an interesting word
that you come across.

You can read about what WeSay has done here
    http://www.wesay.org/blogs/2008/01/

This blog gives more specific reasons for making such a jump, and basic
instructions for developers who want to add these features to other
programs.

If you can do this for Bibledit it would be a real advantage.
Kim

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=658624&aid=1898061&group_id=111189