Network Stack Incomplete & Moving to Farstream/GStreamer

The past two weeks I spent hashing out the details of a much more complex but flexible network stack. I kept running into limitations which required big messy changes.  I also added an account management gui to the cross-platform implementation, since you can have multiple jabber accounts (or none).

Despite the cleaner code, features remain broken or incomplete.  I have added issues for most of them.  The `contact-list-changed` signal never fires for reasons unknown.  I have asked about it in channel multiple times now, and tested on Debian, Fedora, and Sugar with no differences.  I have to assume it is broken, but where I am not sure.  I also have not had enough time to implement creation and deletion of jabber accounts for the accounts UI, nor account selection logic (though the latter may be implemented easily enough).

I decided to spend this weekend creating extensive documentation on TelepathyGLib according to my own experiences.

Sadly, I don’t know if I can finish project goals on time, and I don’t want to spend every waking minute working on it.

When I wrote the proposal, I did so with the idea that the software would be in a near-completed state by the end of the HFOSS course.  The original goal was only to port it cross-platform.  Sadly I ended up saddled with building the incomplete parts and also cross platform porting it.

This quickly turned out to be a lot more than I had planned for, and despite my best efforts I am running far behind schedule over the past 3-4 weeks.

Turns out that the latest GStreamer implementation depends on special network objects, and that required a change in Telepathy package being used, which ended up leading to a second (and third) rewrite of the network stack.  I was not expecting TelepathyGLib to be so horrid to develop with. That has easily put the greatest strain on my time for this project, costing me at least four weeks of productivity.

At this point I am going to put all my remaining development time into getting video working with Farstream. I doubt it is better documented though, so I don’t expect much to come out of this with only two weeks left, especially since I still have plenty of documentation left to complete.

If I can even get decent local video running, I will be happy, since all of the XO laptops I tested on had massive performance problems with the latest GStreamer and scaling video.

Honestly, TelepathyGLib has left a terrible flavor in my mouth as far as OpenSource software goes. It manages to defy the very intention of GObject Introspection by introducing inconsistencies all over the python API (and probably other languages).  I would almost rather have incomplete or even slightly invalid documentation than none at this point.

It’s not that I haven’t been able to get a hold of developers, as they respond quickly in irc, but many times they give me an answer that takes 45 minutes to test and fails, or they simply don’t know the answer.  This has been the case for at least the last three questions.

The library suffers from inconsistencies, and a lack of good examples.  The inconsistencies range from randomly changing constants into undocumented quark methods, or relocating constants forcing me to search for features that I also didn’t know I needed until I specifically read the notes for each method in the chain of methods I was calling.  Some important features also appear to be broken and nobody is even aware of them.

It would be nice to see a table of the features and descriptions of what each does, instead of having to follow each and every method to make sure I’m not missing a feature or chain of features I might need later on.  It would also be great if the abstraction was actually simplifying anything.

If I had examples that clearly explained features and quarks, and a general setup process, that alone might have saved me over three weeks.

In any event, let’s hope I can bring this project to a strong close with working video.

Posted in Uncategorized | Leave a comment

Halfway-Point Update

The past two weeks have been very busy, but not with development so much as events, presentations, travel, and wrapping up with the Summer Undergraduate Research Fellowship (SURF) at RIT. I have been working out of FOSS@RIT with my Mentor (Remy Decausemaker). He has also been advising the SURF team, which have been working out of the same room, this has been great for collaborative reasons.

Two Fridays ago we attended the Undergraduate Research Symposium, where we all presented our research on our projects. I had an opportunity to talk to many people about the OVC project and Sugar, it was a fun event.

Then this past week we all went to Flock, the Fedora Developer Conference, which lasted five days. I gave a short talk to start off a Birds of a Feather for the OLPC and Sugar. The intended plan was to put projects on the board and setup lightning talks. Only a few people showed up so we just briefed various projects (including OVC), and talked. Like all the talks mine was pitted against five others, so I believe it was just poor luck being paired with other talks that people wanted to attend.

Flock was amazing; I have been told that the previous conferences labeled “FUDCons” were not international, so having people from all over the world come together and discuss code and hardware was about the best experience I have had all summer. There were so many other presentations I did not get a chance to see as well, but hopefully the recordings will be a good followup.

I was very excited as I also setup my first instance of Fedora during the trip. I have been working on a Debian installation for a long time, which I used for Sugar development. However Sugar runs on Fedora (usually), so this was rather broken. With a fresh Fedora installation I now have a much better development environment for testing the OVC project.

This upcoming Tuesday I will also be giving a short presentation on Gtk3 at the [Rochester Python Group]() meeting. I hope to present the various tools and workflows that I have found to help with development using Gtk3 given the lack of Python API documentation.

As for the current state of OVC, right now I am between TelepathyGLib issues and Jabber account management. These are key topics:

  • New Icons for Toolbar
  • An Account Management GUI
  • Live Contact List
  • Receiving Channels & Messages

I have a bunch of new icons supplied by Jenn Kotler, part of the SURF team that was brought on to help with design work. She did an excellent job, and now I have a bunch of new icons I wish to integrate into the toolbars.

From what I have gathered thus far, Sugar automatically generates a jabber account using a hash of the .dss public key it generates when setting up a new user. It uses a hash of the private key for the password. The problem is cross-platform development there is not automatic jabber account generation, so ideally we want to create an account manager to create and manage accounts in the OVC Activity.

My other challenge has been a live contact list. I can pull contacts when initializing, but updating the list has proven quite difficult. I know the signal now, but I believe I did not have an asynchronous process still connected in order to receive the changes. This is one of the tougher challenges I am facing.

Then there is receiving channels and messages. I verified that sending works just fine, since I was able to capture messages on another machine using Empathy. What I believe this means is that DBus handles all the messages and channels in the background, and the API is just an interface to all of that. I am not quite sure whether the code I have will do just that yet, but I am hoping so.

As soon as I have the network components sorted I will be able to pickup Farstream and begin building the GStreamer components. I am hoping that I can get started on this before September, but given how difficult getting TelepathyGLib working has been I can’t say for certain.

The good news is the cross-platform build is working great so far. The code I have worked on runs in both environments and behaves the same in each as well.

Posted in Uncategorized | Leave a comment

TelepathyGLib Notes

Yesterday FOSS@RIT was up at 6AM and driving to Wayne County to teach a group of tiny humans programming! It was exciting, and part of the reason no update happened yesterday.

We finished our lessons at noon and returned home to rest up for the hackathon. My car got a flat tire and I had to exchange it for a temporary loaner. I ended up having to hack-from-home and was a bit late joining the session.

The hackathon lasted until 2AM, so by the time I finished doing the work it was already today, hence the late updates.

I have some new and unanswered questions for the Telepathy IRC channel:

  1. How can I prevent a channel request from creating a widget in Gnome?
  2. What is the context used for when I run `ensure_and_handle_channel_finish`?
  3. How do I update the contact list in python?

A widget pops up, but appears to be tied to my software. Not really a huge deal, but it would be nice to not have a widget popup, as it may confuse users.

The contact list is somewhat important, and also erratic. Documentation about a non-existent method or non-existent signals is there, I tried, they don’t work. It may also have to do with missing feature quarks, in which case where do I go to learn what each quark actually adds to the objects?

Back to the Telepathy code I have been working on, I discovered how to create channels last night. The only thing preventing me from testing was a second virtual machine and jabber account to connect with.

This means I can create a channel on one client, it does not mean the listener is working, so I won’t have much to post with accuracy until Monday.

It does establish a channel with the gnome3 bug mentioned above, opening a widget which is tied to the program. If there is a way to stop that behavior I want to know, which is where #telepathy irc comes in.

Once I have tested the listener I will post the whole process in detail.

Posted in Uncategorized | Leave a comment

TelepathyGLib Notes

Today my goal was to put together some questions to ask in the telepathy channel. As a moderately inexperienced OpenSource developer, I can probably figure out the answers quicker by asking than by reading raw C.

There are a few things in particular I wanted to know as of this morning:

  1. What is the difference between a Channel and a Tube?
  2. Is there a circumstance where I might rather use a Channel than a Tube for Streaming Media?
  3. Can we have more than one private text channel open at a time to the same contact?
  4. Is there a python example of tp_base_contact_list_contacts_changed for keeping a list of contacts up to date?

Before I asked I decided to give the documentation on their website another look, because maybe things will make more sense now that I’ve started to run through the code in python.

The terminology section only has tubes listed under a dispatcher, but that isn’t very clear. From what I had read outside the docs is that tubes are for streaming media and dbus, but under channels it mentions StreamedMedia.

With this in mind I opened the channel documentation, armed with knowledge on how to define a private text channel:

    channel_description = {
        Tp.PROP_CHANNEL_TARGET_HANDLE_TYPE: int(Tp.HandleType.CONTACT)   # What it is tied to (A Contact)

Of course if you are opening the channel to connect to another person you specify their contact information. However, the idea is that if the channel HandleType is GROUP then you can “name” it according to the docs, by setting `TelepathyGLib.PROP_CHANNEL_TARGET_ID` to a string of your choosing. For XMPP it gives an example of “”.

The question I have now is whether we can define multiple private channels between the same two contacts, and whether we can or need to name them?

Among the Channel Types we see Tubes for DBus and Media.

I took a break from researching Channels to ask my questions in the #telepathy IRC channel.

While waiting on a reply I investigated Gtk3 again to create the infrastructure needed to test channel establishment.

Using the gtk3 python docs and the gtk3 docs I managed to put together a list and callback methods shared between the network stack and gui.

I now have the network stack pull the contacts and populate the list. The list can be sorted and has a GtkEntry tied to the search process. Double clicking a contact can pull them down and eventually will be tied to a method to initiate a channel.

The code for the GtkTreeView looks like this:

    # Create Buffer for user storage
    self.user_list_store = Gtk.ListStore(str, Contact)

    # Create a Tree View and supply it the List Store
    user_list_tree_view = Gtk.TreeView(self.user_list_store)

    # Define the columns of the Tree View to render the data
    user_tree_view_column = Gtk.TreeViewColumn(
        "User Alias",            # Column Title (is displayed)
        Gtk.CellRendererText(),  # Renderer Component
        text=0                   # Column Index

    # Sort by the alias column

    # Add the column to the Tree View

    # Create a scrollbox for user list
    user_list_scrolled_window = Gtk.ScrolledWindow(hscrollbar_policy=Gtk.PolicyType.NEVER, vscrollbar_policy=Gtk.PolicyType.AUTOMATIC, min_content_height=(MIN_CHAT_HEIGHT - 20))

    # Add a click handler to the tree view for user selection
    user_list_tree_view.connect('row-activated', self.user_selected)

    # Build Search Entry
    user_list_search_entry = Gtk.Entry(max_length=MAX_CHAT_MESSAGE_SIZE)
    user_list_search_entry.set_tooltip_text(_("Search for contacts..."))

    # Apply the search entry to the Tree View

Populating the list is done by a separate method called from the network stack, and you can define as many components as desired (technically I could reduce the data in the list to just two strings). I was testing the flexibility of the List Store by storing Telepathy Contacts in it.

The only thing I have left to figure out here is how to dynamically update the list when users change. If a new user logs in, or another user logs out I want to update the list to reflect this.

I got a response from sjoerd in #telepathy (IRC), and they confirmed that only one text channel between a contact is possible.

While that is unfortunate when I posed my problem with a command channel to toggle video and audio. He suggested Farstream, which I had investigated before and could not find the right version for debian.

Here is the transcript of our conversation:

    15:01:34 CDeLorme | Is it possible to create two text channels at the same time with the same contact?                                                           │ alexandernst_
    15:01:57      <-- | fledermaus ( has quit (Ping timeout: 246 seconds)                                                              │ AmandaC
    15:07:23   sjoerd | CDeLorme: no                                                                                                                                 │ andrunko
    15:14:21 CDeLorme | sjoerd: how would I separate a text channel to share private chat and a text channel to send other text based information?                   │ araujo
    15:15:33   sjoerd | depends on what you're trying to do                                                                                                          │ barisione
    15:16:07 CDeLorme | I am creating a python program that ideally will run a video stream and chat stream.                                                         │ bigon
    15:16:20 CDeLorme | It needs a way to send operational requests, like stopping video on the other end                                                            │ boiko
    15:17:09 CDeLorme | I could parse the text running across the text channel and interpret custom commands, but I was hoping to separate those instead.            │ burger
    15:18:24   sjoerd | Depending on the protocol you can request the other side to stop sending on the call interface already                                       │ cassidy
    15:19:15 CDeLorme | sjoerd: it'll be using gstreamer, the idea is that local and networked audio and video can be individually stopped and started.  The tube    │ CDeLorme
                      | will remain open, just that specific service will change.                                                                                    │ cyphermox
    15:20:08   sjoerd | I'd assume you're using telepathy for the calling as well (with gst and farsight to do the actual media)                                     │ danilocesar
    15:20:38   sjoerd | are you not?                                                                                                                                 │ dvratil
    15:20:54 CDeLorme | sjoerd: gst for the media, not farsight due to version issues.                                                                               │ Elleo
    15:21:06   sjoerd | version issues?                                                                                                                              │ elmo
    15:21:10   sjoerd | well farstream                                                                                                                               │ em-
    15:21:42 CDeLorme | yes, the software is being released on fedora, sugar laptops, and debian, but debian and fedora and the sugar laptops all have different     │ erAck
                      | versions                                                                                                                                     │ felipe`
    15:22:25   sjoerd | that shouldn't really matter that much                                                                                                       │ fredp
    15:23:30   sjoerd | they'll have different versions of gstreamer as well                                                                                         │ fxrh
    15:23:58   sjoerd | the problem with multiplexing text streams is there really isn't a way for most protocols to represent that                                  │ geomyidae__
    15:24:26 CDeLorme | All 3 have 1.0, debian doesn't have modern farsight, but has a backport for 1.0 gst                                                          │ gkiagia
    15:24:51   sjoerd | so add a backport for farstream as well ? :)                                                                                                 │ glassrose
    15:24:55 CDeLorme | Since the software may be talking to XO's with low amounts of cpu to spare, the option to disable one sides video or audio is desired.       │ hagabaka
    15:26:23 CDeLorme | that might be workable, but I haven't checked farstream, it would allow me to send the stop/start operations over the tube instead?          │ Hei_Ku
    15:26:35   sjoerd | the tube?                                                                                                                                    │ inz
    15:26:59 CDeLorme | streamedmedia, I may have channels and tubes mixed up?                                                                                       │ jbos_
    15:27:09   sjoerd | we're using Call these days                                                                                                                  │ jjardon
    15:27:42 CDeLorme | I haven't seen any information on calls yet, any python examples you could link me to?                                                       │ jobstijl
    15:29:21   sjoerd |                                                               │ jonner
    15:30:24 CDeLorme | sjoerd: that is excellent, thank you.  I will have a look at these then.

I checked out farstream again and found that debian has a modern package, and I somehow missed it last time I was searching. So, now armed with a farstream python example repository I have something that looks far easier to establish video/audio communication. While I question the overhead the switch is supposedly more efficient, and newer code which may already be an improvement.

It was nice to have such a quick and informed response, I wish I had started asking questions in IRC sooner.

My last unsolved blocker is how to handle live-updates for the contact list in python. I have not yet received a reply to this, but hopefully by tomorrow I will have an answer, or at least some testable code options.

Tomorrows goals will be:

  • Click User to Initiate a Private Text Channel for Chat
  • Activate the Chat Box & Send button
  • Test Sending Messages
  • Begin mockups for an account management page

Also Jenn, a member of RIT’s SURF (Summer Undergraduate Research Fellowship), recently returned from a visit to the White House as the team lead for the SkyTime project which selected for the Champions of Change event during the National Day of Civic Hacking. She has a blog for the project as well.

While our programs differ we work out of the same room, and since she has two weeks left for her program I decided to ask her for some advice on the UI for OpenVideoChat. We concluded that changes to some of the icons might help, such as local video and audio could use new buttons. She suggested a Webcam icon and a Mic, which would help differentiate between the two.

Posted in Uncategorized | Leave a comment

Python TelepathyGLib Notes

Today is the first day going forward where I will be creating daily documentation and posting my findings as I explore and experiment with TelepathyGLib in Python.

I do this in the hopes that others can see the difficulty of attempting to figure out an undocumented library and make greater efforts to mitigate that when creating API’s in the future.

I am very thankful that collabra has provided modern python documentation in their latest repository. However many things are still a mystery.

I still don’t fully understand the heirarchy of TelepathyGLib, and it would be incredibly helpful if someone could release a diagram that shows the relationships and ownership between all major objects in the stack.

Also, I still have not figured out the difference between a Tube and Channel, but today I started with attempting to create a channel. So I will now list the bugs and blockers I ran into in the process, and if I overcame them, how.

I won’t be posting much raw code in these updates, so check out the repository if you want to see the code changes.

The first confusing problem I ran into was naming in the examples. There are two ways to request a channel. You can create, or ensure. According to the documentation ensure will re-use existing channels, create makes a new one.

None of the examples show channel creation, and they also do not explain how to name a new channel. Thus, how can we create two or more text channels used for different purposes? I am assuming the create method will need to be used.

Besides naming there is also no way to specify the service using that channel. This means the same channel could be “ensured” by telepathy accross multiple applications? Who knows?

So ambiguous channel access, and no details as to whether multiple text channels can be supported at the same time is one problem. I have not yet solved this as I have not reached a state where I can test my theories.

The second problem I ran into was the naming scheme in the examples. The ensure-channel example shows how to define a text vs stream channel (or is the second a tube?). There are also two files that confused me the most.

There is an offerer and an accepter, and you might think that to accept you need to receive an offer, but that is not true in the land of telepathy. I think it makes more sense to call one a listener and the other a sender, but hey what do I know, maybe it’s C terminology.

In any event, I tried to setup the offerer first only to find out that I cannot create a channel that connects to myself. The good news is this means channel creation works, the bad news is I need to pull a communication buddy from the contact list.

The biggest problem is no infrastructure was in place, so I spent the remainder of the day preparing to add the contacts to the Gui and for more robust testing.

Which brought me to my third problem, and the biggest current blocker.

Once the contact list is pulled, how does it update? The method in C is obfuscated, and to my knowledge there is no simple python method. Instead it requires the contact list object to maintain persistent state. This throws a big monkey-wrench into the code and I am now reading the C code to find the solution.

The method I am looking at to watch for changes is only in C examples currently, for example `telepathy-glib-0.20.0/examples/cm/contactlist/contact-list.c` in the source has the method `tp_base_contact_list_contacts_changed`. I am still working to figure out how to tie it something in TelepathyGLib from python.

I found the method definition in C inside `base-contact-list.c`, and am in the process of figuring out how it works so I can try implementing it in python.

Tomorrows Plans:

  • Load Contact List into GtkTreeView or GtkListStore
  • Attach Contacts Dynamically (to accomodate persistent object changes)
  • Attach Filter from Search Input
  • Remove Search Button if able

Then I need to add a double-click event to trigger channel creation on the selected user. At the very least I expect to have the channel creation working tomorrow, but the dynamic attachments and live-contact list may not be possible.

Posted in Uncategorized | Leave a comment

Project Update (Week 5)

This week was very productive. I tried to contact former developers of OVC, I made contact with trose in IRC regarding the project, and sent an email to jlew. I have not yet heard back from jlew, and trose did not recall the details surrounding GStreamer frame rate limitations.

I found out that the gi repository now has TelepathyGLib (case sensative) which appears to have the right methods but next to zero documentation on how to use it.

During last weeks meeting I was told by Walter Bender to contact tch and rgs regarding dbus and Gtk3. I asked rgs about Gtk3 and main loops. I received confirmation that the Main Loop in the gi repository set is fully abstracted and that asynchronous calls from other components automatically attach to it, such as those from TelepathyGLib.

I had help from threebean (Ralph Bean) with testing, and after several failed attempts to locate valid sensible documentation, we finally found out how TelepathyGLib worked. To my surprise the latest source code available from their repository actually carries modern examples of Python, which helped to finally make sense of the library.

The library itself feels very accessible, and a number of the methods from the C documentation can be found as easily as those from the Gtk3 set. However, several key methods do not exist. The C library varies and behaves much differently from the Python implementation.

With the repository examples I was able to make sense of how Python interacts with TelepathyGLib, in particular its asynchronous methods. Python TelepathyGLib uses `quark` methods.

So let’s explore quark methods, what are they, what do they do, and how do they work.

The quark methods belong to TelepathyGLib components. For if you explore the `TelepathyGLib.Connection` you will find methods like `get_feature_quark_contact_list()`.

If you print the output from these methods you get back queer values, like numbers and letters. This is because these methods represent features, and do not actually cause anything to happen on their own.

Instead, the entire TelepathyGLib library as abstracted by a factory, and you use the quarks as feature-codes to tell the factory what components to load during asynchronous processing.

So, let’s run through an example of this. Below is a copy of the basic source code to pull down contacts from a jabber account:

    #!/usr/bin/env python2.7
    # Test connection manager from telepathy-glib

    from gi.repository import Gtk
    from gi.repository import TelepathyGLib as Tp

    def am_ready(am, status, data):

        for account in am.get_valid_accounts():
            connection = account.get_connection()

            if connection is not None and \
               connection.get_contact_list_state() == Tp.ContactListState.SUCCESS:
                contacts = connection.dup_contact_list()
                for contact in contacts:
                    print "%s (%s)" % (contact.get_identifier(), contact.get_contact_groups())


    def begin_test():

        account_manager = Tp.AccountManager.dup()

        factory = account_manager.get_factory()


        account_manager.prepare_async(None, am_ready, None)



Let’s break this down into sections to make sense of it.

    # We import Gtk for our main loop (like we would with a frontend) and rename TelepathyGLib for ease-of-reference
    from gi.repository import Gtk
    from gi.repository import TelepathyGLib as Tp
    # The program is "initialized" from the bottom line

    # This method is called asynchronously and receives the account-manager that the async call was tied to, it's status,
    # and optional data submitted through the method (by the user)
    def am_ready(am, status, data):

        # The asynchronous operation continues to exist until we close it like this:
        # I assume the status is supplied so that it can terminate and trigger appropriate handlers if attached

        # For each account found during the async process get the connection
        for account in am.get_valid_accounts():
            connection = account.get_connection()

            # If we have a connection & the contact list exists (confirmed by state) we can grab the list and iterate it
            if connection is not None and connection.get_contact_list_state() == Tp.ContactListState.SUCCESS:
                contacts = connection.dup_contact_list()
                for contact in contacts:
                    print "%s (%s)" % (contact.get_identifier(), contact.get_contact_groups())

        # Supposedly additional signals can be checked for if the contact list state is not SUCCESS

        # Quit Loop to end this demo

    # This is the function that initiates the test
    def begin_test():

        # Grab us some/an (which?) account manager
        account_manager = Tp.AccountManager.dup()

        # acquire the factory (shared component between TelepathyGLib objects?)
        factory = account_manager.get_factory()

        # Tell the factory that when it runs async to add features using quarks
        # Notice wrapped in [], because you can add multiple features
        # If we did not modify all of the features above we would have to run separate async processes

        # Now run async processing
        account_manager.prepare_async(None, am_ready, None)
        # This also accepts a GQuark feature list as the first argument
        # we supply none for that and custom data, plus the callback function (which receives None for custom data)
        # This can be useful if you wanted to supply some kind of data to the callback method from the caller

        # Start main loop

    # Begins test

_Note: The above code assumes your jabber account is already registered on the system, if you have no account it will pull nothing._

I am still not clear on all of the details myself, but this should give a pretty solid overview of what is actually happening in the code.

With this knowledge in mind the upcoming challenges are as follows:

  • Implementation of multiple channels (preferably in a one-to-one build)
  • Implementation of jabber account creation/registration
  • Creating a stream channel for GStreamer
  • Testing on the XO laptops

I suspect that the XO laptops may not have the CPU power necessary to handle two independent video streams. So far I have made no progress in improving the framerates of local video, which seems to be cut off around 22 fps. Adding scaling reduces this event further, which may indicate the processing power needed to do scaling is too heavy.

Some suggestions by lmacken were to run independent streams to reduce processing required to separate them for rendering. I am still waiting to see if jlew comes back with some suggestions, and when I reach the stage where I am testing on the XO’s I will try asking Sugar developers.

Before I conclucde my report I also want to register a complaint with API’s.

Not everyone knows C. Introspection may be an awesome tool meant to help us save time by automatically generating documentation, but if they are also responsible for automatically generating API’s then they already have all the rules and definitions and should be generating the documentation for those APIs.

I am all for saving time and money, but I have done nothing but loose time since working with these newer APIs. Reading C documentation and magically translating unwritten API rules should not be part of my workflow to develop in Python.

Posted in Uncategorized | Leave a comment

Project Updates (Week 4)

I spent this last week reading more about Telepathy and attempting to discover how to best create a communication channel that is cross platform compatible and already built into the Sugar OS.

As it turns out Sugar automatically registers a jabber account on creation using a dss ssh key, by hashing the pub and private to a username and password. The process seemed a bit confusing so I questioned whether the jabber server is a standard server or a customized one.

I spoke with alsroot who confirmed it was a normal server, and tested this by creating a new account from a software called Gajim. Gajim is actually built in python so I intend to use it as reference material, but I believe it uses Gtk+ not Gtk3, which could lead to a lot of incomplete or inefficient code.

Fortunately during the meeting on Friday I was told to speak with rgs and tch about this if I ran into any blockers. As of the end of day Friday I had read roughly 45% of the official telepathy documentation, and about half a dozen guides on creating client and server components, but still feel no closer to understanding how it actually works.

On Thursday I did spend a bit of time reworking my milestones and deadlines to make more sense, having discovered that the diagramming process was going to be quite difficult without the right information.

With week 5 starting tomorrow I hope to push forward and get network communications working with multiple channels. If I can manage this much it will eliminate the biggest blocker standing between me and working video communication. I expect this will be quite a challenge given my still limited understanding of dbus and telepathy, but I expected that when I chose this project.

On Tuesday we have a rocpy meeting, and I am thinking I might my lightning talk on what I have learned about building python with Gtk3.

I know todays post is a bit small compared to normal, but believe me when I have something to share I will be certain to do so as verbosely as possible.

Posted in Uncategorized | Leave a comment