Difference between revisions of "Activities/FileShare"

From Sugar Labs
Jump to navigation Jump to search
Line 8: Line 8:
  
 
==Project Status==
 
==Project Status==
The project is under active development.  I am currently looking for bug reports as well as suggestions for further improvement.  Check out the current Dev Release (Dec. 14, 2009) or source code.
+
The project is under active development.  I am currently looking for bug reports as well as suggestions for further improvement.  Check out the current Dev Release (Dec. 15, 2009) or source code.
  
 
If you have found a bug, please report it the google group page or email to our google group email address.
 
If you have found a bug, please report it the google group page or email to our google group email address.
Line 15: Line 15:
 
* Activity can be loaded up and files can be added and removed from the file list
 
* Activity can be loaded up and files can be added and removed from the file list
 
* It can be shared and users who join are able to download files (journal entries) from the file list and have them installed into their own journal.
 
* It can be shared and users who join are able to download files (journal entries) from the file list and have them installed into their own journal.
 +
* Activity is able to keep and resume
 +
** On closing, the files and file list is stored in the activity entry and can be restored.
 +
** One advantage to this is an instance of this activity can be shared and the files remain with it.
 +
* The server is able to copy files back to the journal
 +
** Useful when restoring the activity and would like to get a file back that may have been deleted or modified.
 +
  
 
==Bugs==
 
==Bugs==
 
* Sometimes user interface can become un-responsive during file transfers.
 
* Sometimes user interface can become un-responsive during file transfers.
 +
* (Untested, but looks like this will be problematic)Client downloads file and then disconnects. The server then removes a file and re-adds file (after changing it).  When the client re-connects (resumes) the client will not know that the file changed and not allow them to download the new one.
 +
** Work around: Close the activity and delete it's entry in the journal. When re-connecting, it will allow all downloads as expected as it doesn't know that you already downloaded that file.
 +
  
 
==Future Plans==
 
==Future Plans==
Line 25: Line 34:
 
** Download count on each file
 
** Download count on each file
 
** Prevent/Notify user from closing the activity while users are downloading from them.
 
** Prevent/Notify user from closing the activity while users are downloading from them.
 
* Activity should be able to save its state
 
** Next time it loads up, the activity should be able to restore the file list and continue sharing.
 
** This feature would be helpful for a teacher to save files related to the day's lesson and then be able to recall it at a later time.
 
  
 
* Integration to the school server
 
* Integration to the school server

Revision as of 19:59, 15 December 2009

Shared activity downloading files

FileShare is an activity that allows the user to share files from their journal.

The activity prompts the user for a list of files. When a user joins the shared activity, they are shown the file list where they can choose which files they would like to download.

The activity was based off a concept activity called Distribute

Project Status

The project is under active development. I am currently looking for bug reports as well as suggestions for further improvement. Check out the current Dev Release (Dec. 15, 2009) or source code.

If you have found a bug, please report it the google group page or email to our google group email address.

Features

  • Activity can be loaded up and files can be added and removed from the file list
  • It can be shared and users who join are able to download files (journal entries) from the file list and have them installed into their own journal.
  • Activity is able to keep and resume
    • On closing, the files and file list is stored in the activity entry and can be restored.
    • One advantage to this is an instance of this activity can be shared and the files remain with it.
  • The server is able to copy files back to the journal
    • Useful when restoring the activity and would like to get a file back that may have been deleted or modified.


Bugs

  • Sometimes user interface can become un-responsive during file transfers.
  • (Untested, but looks like this will be problematic)Client downloads file and then disconnects. The server then removes a file and re-adds file (after changing it). When the client re-connects (resumes) the client will not know that the file changed and not allow them to download the new one.
    • Work around: Close the activity and delete it's entry in the journal. When re-connecting, it will allow all downloads as expected as it doesn't know that you already downloaded that file.


Future Plans

Functionality

  • Clients needs to communicate more to the server. In the current state, the server is not aware of the number of clients currently downloading files.
    • Should show user who is currently downloading what files
    • Download count on each file
    • Prevent/Notify user from closing the activity while users are downloading from them.
  • Integration to the school server
    • Current plans are to have a server running on the school server as well allowing authorized users to upload files to the school server as well.

UI

  • Download All Button
  • Download file in each row instead of selecting each file then clicking download
    • Alternatively, support selecting multiple rows and then click download.
  • Display icons for the journal entry type

Change Log

Detailed change log can be found on our change log page in our google group.

  • 2009-12-11: Initial release
  • 2009-12-14: FileShare-2.xo
  • 2009-12-15: FileShare-3.xo

Links