Document sharing issues
Morgan, I did some work on View Slides over the weekend and I got the document sharing code to work OK. There are still some bugs, but they are not related to sharing, at least not directly. However, in fixing the code I discovered the following issues: 1). Unlike the core Read activity, my activities save shared files as Journal entries. If the child wants to resume reading when the document is no longer being shared he can get the document from the Journal with no problem. Unfortunately, if the document *is* still being shared it will be downloaded again, whether it needs to be or not. Ideally, if the kid already has the document and it is the same size as the one being shared the download would not happen. How do I accomplish this? 2). Downloading a document is very slow. I distribute View Slides files on an Apache server, using the Browse activity to copy same to the Journal. This takes under a minute even for a large file (over 15mb). Then I share the document with another instance of Sugar on the same box. *That* is agonizingly slow. I know the two instances are not communicating directly, but it still seems like there is a lot of overhead going on. Can I do anything about this? 3). Because downloading documents is so slow, I have modified my Read toolbar to have a running count of bytes downloaded so the user doesn't have to stare at an unchanging screen for several minutes wondering if anything is going on. In the core Read code I modified to do this there is a comment that it would be good to signal the file size of the file being sent, so the user could see a progress bar. The author never got around to doing that, so I don't know how to do that either. How would I go about it? If you're curious about my code the latest is in the git repository and I have a page for View Slides linked from the OLPC Activities page. Thanks, James Simmons Morgan Collett wrote: >If you get stuck with View Slides, I'll be happy to take a look. > > >The Read activity is definitely on my list as the sharing was found to >have reliability issues in recent testing. > >Regards >Morgan > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Document sharing issues
Hi James, > 3). Because downloading documents is so slow, I have modified my > Read toolbar to have a running count of bytes downloaded so the > user doesn't have to stare at an unchanging screen for several > minutes wondering if anything is going on. In the core Read code I > modified to do this there is a comment that it would be good to > signal the file size of the file being sent, so the user could see > a progress bar. The author never got around to doing that, so I > don't know how to do that either. How would I go about it? You should be able to pull it out of the underlying GlibURLDownloader (getter) headers from inside _download_progress_cb(), like so: size = getter._info.headers["Content-Length"] But, what we should really do is provide an accessor in sugar/network.py. The advantage of the above is that, even though it's groveling inside the downloader internals, it won't require introducing a new API dependency between activities and sugar. Sugar gang, any thoughts? - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Document sharing issues
Le lundi 21 avril 2008 à 10:24 -0500, James Simmons a écrit : > 2). Downloading a document is very slow. I distribute View Slides > files on an Apache server, using the Browse activity to copy same to the > Journal. This takes under a minute even for a large file (over 15mb). > Then I share the document with another instance of Sugar on the same > box. *That* is agonizingly slow. I know the two instances are not > communicating directly, but it still seems like there is a lot of > overhead going on. Can I do anything about this? Were you using Gabble or Salut? Currently Gabble stream tubes still send their data through the jabber server making transfer really slow. I'm working on implementing real p2p instead (#4047). Salut doesn't have this problem though as it already uses TCP connections. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Document sharing issues
Guillaume Desmottes wrote: > Le lundi 21 avril 2008 à 10:24 -0500, James Simmons a écrit : > >> 2). Downloading a document is very slow. I distribute View Slides >> files on an Apache server, using the Browse activity to copy same to the >> Journal. This takes under a minute even for a large file (over 15mb). >> Then I share the document with another instance of Sugar on the same >> box. *That* is agonizingly slow. I know the two instances are not >> communicating directly, but it still seems like there is a lot of >> overhead going on. Can I do anything about this? >> > > Were you using Gabble or Salut? Currently Gabble stream tubes still send > their data through the jabber server making transfer really slow. I'm > working on implementing real p2p instead (#4047). > Salut doesn't have this problem though as it already uses TCP > connections. > Can you elaborate more on this? Isn't TCP the underlying mechanism for Gabble also? How is Salut more efficient? p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Document sharing issues
Le mardi 22 avril 2008 à 04:26 -0400, Polychronis Ypodimatopoulos a écrit : > Guillaume Desmottes wrote: > > Le lundi 21 avril 2008 à 10:24 -0500, James Simmons a écrit : > > > >> 2). Downloading a document is very slow. I distribute View Slides > >> files on an Apache server, using the Browse activity to copy same to the > >> Journal. This takes under a minute even for a large file (over 15mb). > >> Then I share the document with another instance of Sugar on the same > >> box. *That* is agonizingly slow. I know the two instances are not > >> communicating directly, but it still seems like there is a lot of > >> overhead going on. Can I do anything about this? > >> > > > > Were you using Gabble or Salut? Currently Gabble stream tubes still send > > their data through the jabber server making transfer really slow. I'm > > working on implementing real p2p instead (#4047). > > Salut doesn't have this problem though as it already uses TCP > > connections. > > > Can you elaborate more on this? Isn't TCP the underlying mechanism for > Gabble also? How is Salut more efficient? Gabble uses one TCP connection to the jabber server and when you connect to a stream tube, all the data are send using this connection. This is very inefficient because all the data are encoded into base64 XML stanzas and go trough the server (the traffic inside a stream tube can potentially be really big). What we need to do is to establish a *new* TCP connection between the 2 peers of the tube. So data won't have to be encoded to base64 and won't go trough the server anymore. But that's not an easy task as peers can potentially be behind a NAT. So we have to use NAT traversal magic using Jingle, ICE and stuffs as we do for audio/video calls. Salut doesn't have this problem as peers are on the same network and so can directly talk to each other. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Document sharing issues
Guillaume, I was using gabble every time. The Collabora jabber server was up each time I did a test, so I assume that by default I was using gabble. I have not yet tried a test with Salut because that seems to be broken on the computer I have sugar-jhbuild on. (I do have it working on another box, but have not had the opportunity to do a test that way yet.) The stream tube code I use was adapted from the core Read activity. Good luck with getting p2p working. That sounds like it would help a lot. James Simmons Guillaume Desmottes wrote: Le lundi 21 avril 2008 à 10:24 -0500, James Simmons a écrit : 2). Downloading a document is very slow. I distribute View Slides files on an Apache server, using the Browse activity to copy same to the Journal. This takes under a minute even for a large file (over 15mb). Then I share the document with another instance of Sugar on the same box. *That* is agonizingly slow. I know the two instances are not communicating directly, but it still seems like there is a lot of overhead going on. Can I do anything about this? Were you using Gabble or Salut? Currently Gabble stream tubes still send their data through the jabber server making transfer really slow. I'm working on implementing real p2p instead (#4047). Salut doesn't have this problem though as it already uses TCP connections. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
