Sugar Labs - User contributions [en]

Talk:Features/Terminal Sharing

2009-12-06T17:04:29Z

Bemasc:

This sounds quite fun and useful. Is there a reason this couldn't be integrated with the Terminal activity itself, with these features enabled when the activity is shared? -[[User:Eben|Eben]] 02:04, 25 July 2009 (UTC)

: There is no major technical reason that this sharing functionality could not be integrated into the main Terminal activity. However, there is a security issue. The Terminal activity exposes the full power of the user over the machine. On an XO in the default configuration, this includes root access with no password. Even without root access, anyone participating in the activity could easily "rm -rf .sugar" and delete your entire Journal, etc. Advising users not to share the Terminal with people they don't trust might be sufficient... I'm not sure how to reach consensus on this point.

:ShareTerm, simply by not being named "Terminal", is treated as a normal activity, and so is sandboxed by Rainbow... if Rainbow is present. If Rainbow is not present, then ShareTerm has no security advantage at all.

:Adding sharing to Terminal itself, in an unsafe fashion, would have the distinct advantage of allowing deep technical troubleshooting and problem-solving directly over the collaboration system. I could invite an expert onto my machine to perform arbitrary upgrades and maintenance, and watch them as they work. Perhaps you can think of a clever user interface that will ensure "unsafe sharing" is only performed after careful consideration? Perhaps an activity that can only be shared with "Friends"? [[User:Bemasc|Bemasc]] 17:57, 6 August 2009 (UTC)

== Feature Acceptance ==

Hi Benjamin,

what would be the downside of packing the needed packages inside the activity? I guess one criteria for adding to the platform is: is this worthy for several activities? -[[User:Erikos|Simon Schampijer]] 04 August 2009 (UTC)

: My principal reason for wanting Screen to be a Sugar dependency is to avoid shipping binaries inside .xo bundles. I strongly believe that .xo bundles should be "noarch", to run on any platform. I would be happy to ship the Screen source code and compile it on the user's machine, but gcc is not a sugar dependency either.

: Additionally, as Eben noted, the functionality described here is quite close to Sugar's fundamental mission, and there is an argument for including it in Terminal. Making Screen a Sugar dependency allows us to make these kinds of decisions later. It also opens a door for other shared activities that make use of a shared command line. [[User:Bemasc|Bemasc]] 17:57, 6 August 2009 (UTC)

Hey Benjamin,

Is there a way that this technology could be achieved without the dependencies, while maintaining security? I'm wondering about sending input and output over encrypted tubes rather than relying on sshd, and using some kind of key event trapping to redirect input instead of screen. It would be nice to keep Terminal's scrollback functionality etc. while sharing. Perhaps you should post this activity to ASLO with instructions for installing the dependencies. Bonus points for trapping the lack of the dependencies and showing a legible error message at startup! [[User:Wade|Wade]] 12:55, 21 September 2009 (UTC)

: I'm not using SSH here to maintain any kind of security. In fact, it provides little cryptographic security, because the private key for the session is known and fixed. I'm using it simply because RSH (unencrypted remote shell) is no longer installed in most distributions. SSH is being used here to provide bidirectional terminal access over the network. This is difficult to achieve in any other way due to the notorious vagaries of the TTY subsystem.
: I haven't found any easy way to achieve the desired functionality without using Screen and OpenSSH. These seem like fairly harmless dependencies to me, since OpenSSH is already installed on almost every Sugar machine, and GNU Screen is already installed on many or most Linux desktops.
: In contrast to Terminal Sharing, Sayamindu has recently implemented a sort of [http://lists.sugarlabs.org/archive/sugar-devel/2009-November/020799.html "Terminal Watching"] functionality. He used the accessibility features of our Terminal widget to scrape the screen and send it over a tube. This is also interesting, and does not introduce any new dependencies. It is, however, a less powerful form of collaboration. [[User:Bemasc|Bemasc]] 17:04, 6 December 2009 (UTC)

Summer of Code

2009-08-25T00:47:47Z

Bemasc: fix link

Summer of Code

2009-08-24T21:57:26Z

Bemasc: Add Groupthink project info

Talk:Features/Terminal Sharing

2009-08-06T17:57:38Z

Bemasc:

WebCollab

2009-07-30T20:19:07Z

Bemasc:

Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API.

Programs written in Javascript+HTML+CSS, designed to run in a browser, can also provide online collaborative behaviors, as evidenced most famously by Google Docs. However, this collaboration typically requires a cooperating central server, because the standard browser security model does not permit a javascript application to communicate directly with any computer other than the server.

This page presents a simple design to enable decentralized, serverless collaboration between javascript applications. This model also extends naturally to environments in which a central server is available.

==Architecture Overview==
WebCollab employs a server, the HTTPCollab server. The javascript webpage interacts with this server by downloading files from it and uploading files to it. For a single central server, that's all there is to it.

To enable decentralized operation, such as would be expected when using Telepathy, the servers talk to each other. Every time a local user uploads a file to the local server, the local server transmits the file to all the other servers, which make it available at the same path. Javascript clients are expected to poll directories that may contain messages in which they are interested, so the system acts as a message-passing interface with named messages. A client that uploads a file can reasonably expect that all other clients will soon become aware of that file's existence.

Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server.

==Type-0 Design==
The Type-0 design is the simplest useful implementation of this architecture. It does not provide a high degree of efficiency or security, but it permits the full range of desired client behaviors.

===The Type-0 HTTPCollab Server->Client Interface===
In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie.

As far as a simple server is concerned, this describes its entire interaction with the client.

===The Type-0 JSCollab Client->Server Interface===
The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior.

A JSCollab client has a unique id during each session. This id may be a random string, and it need not be the same from session to session. The id must be a valid HTTP path name and must not contain the characters "_" or "/".

A message in JSCollab has a key, a value, and an index. The key is a string subject to the same constraints as the unique id. The value is a sequence of arbitrary bytes. The index is an integer indicating the number of messages previously sent by the user, incremented for each message, starting at 0.

To broadcast a message, a JSCollab client uploads a file with the name {unique id}_broadcast_{index}_{key}. The contents of the file are the value of the message. The index is represented as a base-10 string.

To send a message to a specific user specified by a target id, the client uploads a file with the name {unique id}_to_{target id}_{index}_{key}

For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file.

===The Type-0 SugarHTTPCollab Server->Server Interface===
In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/).

The server is configured to accept all PUT and DELETE requests in collabdir/. If the activity is already shared, the PUT or DELETE request is immediately also transmitted to all other collaborating server instances.

When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release.

==Refinements==
===The Type-1 HTTPCollab Server->Client Interface===
The Type-0 Server has two obvious deficits: efficiency and security. Efficiency is low, in the sense that if A sends a message to B, C will have to download the whole list of messages again to find out that the message is for someone else. Security is low, in the sense that any user can easily impersonate any other, or interfere with others' communications.

To enable greater efficiency, an obvious step is to introduce directories. Messages to one user may be segregated in a separate directory, so that users do not have to monitor each others messages.

To enable greater security, an obvious step is to employ access control permissions on these directories.

HTTP provides, or at least enables, some types of access control, but it does not provide any standard way for users to create directories. We could build such a system with POST messages, but a more standards-based approach is available through WebDAV. The WebDAV HTTP extensions include a MKCOL message type, allowing clients to make directories. WebDAV also provides a suitable access control mechanism for directories, in the form of Write Locking.

A Type-1 HTTPCollab Server provides a WebDAV interface, including at least GET, PUT, DELETE, and MKCOL. If security is desired, it should also provide LOCK and UNLOCK.
===The Type-1 JSCollab Client->Server Interface===
A Type-1 JSCollab client implements the same abstraction as a Type-0 client, but using directory structures and locking to improve efficiency and security.

The client first chooses a unique id, then uses the LOCK directive to acquire a depth:infinity write lock on the directory with that name. This lock will never be released. If high security is desired, it may be necessary to choose a random name to ensure that no other user could have locked it already.

The client then creates the directory with that name. Within that directory, the client creates two subdirectories: "broadcast/" and "to/". A broadcast message that would be "{unique id}_broadcast_{index}_{key}" in Type-0 becomes "{unique id}/broadcast/{index}_{key}" in Type-1.

If a user wishes to send a message to another user, the user must create a subdirectory of "to/" with the desired target id. Once created, such a directory should not be deleted. A directed message that would be "{unique id}_to_{target id}_{index}_{key}" in Type-0 is "{unique id}/to/{target id}/{index}_{key}" in Type-1.

A Type-1 client must monitor the root collaboration directory for the appearance of new users. When a new user appears, the client must monitor that user's broadcast/ directory for broadcast messages. The client must also monitor that user's to/ directory in case a message with the client's unique id should appear. If such a directory does appear, the client may stop polling to/, but must start polling to/{unique id}.

The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server.

===The Type-1 SugarHTTPCollab Server->Server Interface===
This interface is the same as the Type-0, updated to include directories and optionally locking.

JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client. One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock". If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token. If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no". The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token. Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.

This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.

*: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.

WebCollab

2009-07-30T18:21:58Z

Bemasc:

WebCollab

2009-07-30T17:36:18Z

Bemasc:

WebCollab

2009-07-30T17:16:49Z

Bemasc: /* The Type-0 JSCollab Client->Server Interface */

WebCollab

2009-07-30T17:12:53Z

Bemasc: Created page with 'Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed th…'

Features/Terminal Sharing

2009-07-22T17:00:45Z

Bemasc:

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

== Summary ==
This feature represents [http://dev.laptop.org/~bemasc/ShareTerm-1.xo ShareTerm], an Activity providing a shareable version of Terminal so that users can interact over the network at a single command prompt.

== Owner ==
* Name: [[User:bemasc| Ben Schwartz]]

* Email: bmschwar@fas.harvard.edu

== Current status ==
* Targeted release: 0.86
* Last updated: 2009-07-22
* Percentage of completion: 100%

== Detailed Description ==
ShareTerm is
a variant of Terminal designed to enable collaborative work at the command
prompt. ShareTerm works by starting an unprivileged SSH daemon and a GNU Screen
session. The SSH daemon is tunneled over a Telepathy Stream Tube. To
avoid the need for passwords, public-key authentication is used. The
system should support an arbitrary number of participants, though at the
moment the sshd is configured with a maximum of 10.

== Benefit to Sugar ==
I hope that ShareTerm will be useful for teaching UNIX and programming
skills to novices. For experts, the window management of Screen will be
especially useful.

== Scope ==
The only change required to Sugar is to add a dependency on GNU Screen and OpenSSH, which are available in every distro's package system. I think ShareTerm may merit inclusion in Fructose, but the important thing is to make Sugar-0.86 depend on Screen.

== How To Test ==
* Install the bundle from:
http://dev.laptop.org/~bemasc/ShareTerm-1.xo
* Install GNU Screen on your system. MANDATORY. NOTE: GNU Screen is not
installed by default on many Sugar systems, including OLPC's XO distributions.
* Make sure you are running with Rainbow enabled!
* Start ShareTerm from the Sugar UI, and then share it like any
collaborative Activity

== User Experience ==
Shared Terminal. Each user can type into the same shared instance from different machines, and their keystrokes will all register. The instance actually runs on the initiator's computer.

== Dependencies ==
GNU Screen and OpenSSH. If security is a consideration, then Rainbow is an important requirement as well. Running ShareTerm allows any friend who joins the activity to run arbitrary commands on your computer. Rainbow ensures that these commands are run as a restricted, unprivileged account. If you are running without Rainbow, you should be sure to invite only people you trust to your ShareTerm!

== Contingency Plan ==
Tell people to install GNU Screen and openssh manually before installing shareterm, or possibly try to package static binaries into the .xo. Neither is ideal, especially because ShareTerm is most appropriate for users who are not yet comfortable with the command line.

== Documentation ==
http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014165.html

== Release Notes ==
No significant changes are noteworthy here.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

[[Category:Feature_Ready_for_Release_Manager]]
[[Category:Feature]]

Features/Terminal Sharing

2009-07-22T16:53:58Z

Bemasc: Created page with '<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> == Summary == This feature represents [http://dev.laptop.org/~bemasc/ShareTerm-1.xo ShareTerm], an Activity providing a sha…'

<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>

== Summary ==
This feature represents [http://dev.laptop.org/~bemasc/ShareTerm-1.xo ShareTerm], an Activity providing a shareable version of Terminal so that users can interact over the network at a single command prompt.

== Owner ==
* Name: [[User:bemasc| Ben Schwartz]]

* Email: bmschwar@fas.harvard.edu

== Current status ==
* Targeted release: 0.86
* Last updated: 2009-07-22
* Percentage of completion: 100%

== Detailed Description ==
ShareTerm is
a variant of Terminal designed to enable collaborative work at the command
prompt. ShareTerm works by starting an unprivileged SSH daemon and a GNU Screen
session. The SSH daemon is tunneled over a Telepathy Stream Tube. To
avoid the need for passwords, public-key authentication is used. The
system should support an arbitrary number of participants, though at the
moment the sshd is configured with a maximum of 10.

== Benefit to Sugar ==
I hope that ShareTerm will be useful for teaching UNIX and programming
skills to novices. For experts, the window management of Screen will be
especially useful.

== Scope ==
The only change required to Sugar is to add a dependency on GNU Screen and OpenSSH, which are available in every distro's package system. I think ShareTerm may merit inclusion in Fructose, but the important thing is to make Sugar-0.86 depend on Screen.

== How To Test ==
* Install the bundle from:
http://dev.laptop.org/~bemasc/ShareTerm-1.xo
* Install GNU Screen on your system. MANDATORY. NOTE: GNU Screen is not
installed by default on many Sugar systems, including OLPC's XO distributions.
* Make sure you are running with Rainbow enabled!
* Start ShareTerm from the Sugar UI, and then share it like any
collaborative Activity

== User Experience ==
Shared Terminal. Each user can type into the same shared instance from different machines, and their keystrokes will all register. The instance actually runs on the initiator's computer.

== Dependencies ==
GNU Screen and OpenSSH. If security is a consideration, then Rainbow is an important requirement as well. Running ShareTerm allows any friend who joins the activity to run arbitrary commands on your computer. Rainbow ensures that these commands are run as a restricted, unprivileged account. If you are running without Rainbow, you should be sure to invite only people you trust to your ShareTerm!

== Contingency Plan ==
Tell people to install GNU Screen and openssh manually before installing shareterm, or possibly try to package static binaries into the .xo. Neither is ideal, especially because ShareTerm is most appropriate for users who are not yet comfortable with the command line.

== Documentation ==
http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014165.html

== Release Notes ==
No significant changes are noteworthy here.

== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] 

[[Category:Category:Feature_Ready_for_Release_Manager]]
[[Category:Feature]]

Design Team/Meetings

2009-05-09T14:20:43Z

Bemasc: /* Next meeting */

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TeamHeader|Design Team|roadmap_link=Vision|roadmap_label=Vision}}</noinclude>
__NOTOC__
== Who and what==
The meeting is targeted to Sugar core and activity developers, but remains open to anyone interested. It's primary purpose is to open the design approach, making it more transparent and allowing the community to provide feedback on both current and upcoming features.

In general, discussion focuses on:
* high level design goals and ideas
* feedback and discussion of problems in the current design
* reviews of design proposals

To convert UTC to your local time, use [http://www.timeanddate.com/worldclock/converter.html?hour=11&min=30&sec=0&p1=0&p2=43 this converter] or run:
date -d '[current date] [time] UTC'
date -d '2008-06-03 14:00 UTC'

== Adding topics ==
You can add topics for discussion to the topics section for the meeting throughout the week. Posted topics will be collected and sent out in the announcement on the morning of the meeting.

== Meetings ==
=== Saturday, 2009 May 9, 10 AM ET ===
==== Topics ====

* Sayamindu's dictionary dialog.
*:See http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg04042.html
* Jameson's accelerators proposals.
*:See [[Design_Team/Vision/Proposals#Keyboard_Action]]
* Printing proposal from several people.
*:See [[Print Support]], http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg03984.html, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg03991.html
* Martin's clock proposal.
*:See http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg03934.html

=== Sunday 19 April 2009 13:00 UTC / 9:00 EDT ===
Log: http://meeting.sugarlabs.org/sugar-meeting.log.20090419_0911.html
==== Topics ====
We discussed design goals for the next release 0.86. Design mockups will be created in response to the high-level features listed below (potentially in advance of SugarCamp 2009 on May 16th), to further illustrate the design intent and allow for integration with the development schedule.

High-level feature recap:

* polish activity list in Home
* support filtering/searching via tags in Home
* add list views to groups/neighorhood
* make groups dynamic (like neighborhood)
* extend activity chat
* add overlay chat to groups/neighborhood
* design a bulletin-board _activity_
* remove management from activity list, ensure _all_ installed activities are in Journal
* new toolbar design

Concrete design/development tasks:

# design mockups to make the frame more discoverable
# design mockups to polish the new toolbars
# Home list view: remove the date column and enable alphabetical sort. Label versions "Version x"
# Design mockups for tagging/filtering/search within Home view
# Draft changes to activity.info file to support tagging
# Design mockups for overlay chat in groups/neighborhood (should also include revising the activity chat..which exists but not as earlier designs proposed)
# Design mockups of bulletin board activity
# Design mockups for list views in groups and neighborhood

=== Saturday 21 March 2009 14:00 UTC / 10:00 EDT ===
Log: http://meeting.sugarlabs.org/sugar-meeting.log.20090321_1009.html
==== Topics ====
Discussion of the Home view and whether to abandon the notion of favorites for a single consolidated view

See [[Design Team/Vision/Proposals]].

Unify look of web services

=== (Marketing Team) Tuesday 10 March 2009 13:00 UTC / 09:00 EDT ===
Log: http://meeting.sugarlabs.org/sugar-meeting.log.20090310_1100.html<br>
Summary: http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg03132.html

=== Sun March 1, 2009 - 13.00 (UTC) / 10.00 EST ===

Logs: [[Design Team/Meetings/09.03.01]]

==== Topics ====

We'll continue discussion of revised, and thorough, mockups for overlay chat in activities. This includes ways in which this chat system can extend into the other zoom levels, and short term and long term goals.

Other topics: Discuss development roadmap and prioritize design activities for next build

=== Friday December 19, 2008 - 15.30 (UTC) ===

==== Topics ====

We'll continue discussion of revised, and thorough, mockups for overlay chat in activities. This includes ways in which this chat system can extend into the other zoom levels, and short term and long term goals.

=== Thursday December 4, 2008 - 15.30 (UTC) ===

==== Topics ====

We'll focus on possibilities for overlay chat in activites, presenting both short term and long term ideas, and discuss how this could later be extended to the neighborhood.

==== Media ====

* [[Media:Overlay_chat_sketch.pdf | Overlay chat sketch (PDF)‎]]

==== Logs ====

* http://meeting.laptop.org/sugar-meeting.20081204_1042.html

=== Wednesday November 26, 2008 - 15.00 (UTC) ===

We'd like to hold a meeting this week while the topics discussed at the recent SugarCamp are fresh in our minds. Though this is not part of the usual meeting cycle, I think it's important enough to merit an extra meeting. Due to Thanksgiving on Thursday, we'll hold it on Wednesday instead.

==== Topics ====
===== Short Term Roadmap Definition =====

To capitalize on the extremely valuable discussions at the recent SugarCamp in Cambridge, we'd like to take some time to define a rough feature roadmap for the Sugar OS within the OLPC 9.1 timeframe. As a starting point for this discussion, we should likely review the various design proposals presented on the last day of the conference.

=====Groups=====
=====Resuming activities from Home=====
=====Enhancing the Journal=====
=====Improving Toolbars=====
=====Encouraging Naming/Tagging=====

==== Logs ====
* http://meeting.laptop.org/sugar-meeting.20081126_1018.html

=== Thursday September 18, 2008 - 15.30 (UTC) ===
==== Topics ====
===== Visual Clipboard API =====
For reference, please see the [http://wiki.laptop.org/go/Specifications/Clipboard clipboard specification]. For a more targeted list of features and goals, please see the [[Development Team/0.84/Clipboard|clipboard planning page]].

We had a fairly long discussion about this, which didn't seem to get too far. Fortunately, a follow-up between Marco and I clarified some points, and we agreed that it should be possible to implement the majority of the goals across the system using the "formats" allowed in the GTK protocols, and falling back to sane defaults when extra info isn't provided.

Some references:
* http://www.pygtk.org/pygtk2tutorial/ch-NewInPyGTK2.2.html#sec-Clipboards
* http://www.pygtk.org/pygtk2tutorial/ch-DragAndDrop.html
* http://www.pygtk.org/pygtk2tutorial/ch-ManagingSelections.html

===== Advancing the Journal =====
I'd like to have a conversation regarding the current iteration of the Journal, future plans, and the steps we hope to take toward them in the next major release so we can scope our goals. The latest mockups (though slightly out of date) can be seen [http://wiki.laptop.org/go/Designs/Journal here].

Due to the lengthy clipboard discussion, we didn't hit this topic today. We'll pick it up first thing next week.

===== Icon reviews =====
We discussed three icons today.

'''Settings (control panel)''': By popular demand, a wrench was chosen as the base for this icon, though it was also proposed that a wrench and screwdriver could be clearer. It was agreed that the wrench is a simpler icon, and a more generic metaphor which could be used to represent "settings" throughout the system. A few visual tweaks {{Trac|8198|}} made many happier with the wrench, but since this isn't a major change they can come post 8.2.

'''View Details (Journal)''': The old designs for this button closely resembled a play button (but with an open triangle, akin to a greater than (>) symbol), which some found confusing. The new proposal is an ellipsis [...] icon, to indicate the idea that more info is available, but omitted in the abbreviated list view. This works nicely within the [wiki.laptop.org/go/Designs/Journal new Journal designs], since the icons will occasionally appear within a string of icon-annotated text. All present agreed the latter was a better direction. This change could make 8.2.

'''Access Point''': Recent experience reports have indicated that the removal of an identifier of the connected AP is frustrating. The proposal discussed is shown [http://interdimensionmedia.com/scratch/devices.png], which wraps the former AP icon (the circle) in "parenthesis" (meant to indicate radio signal). This retains the primitive circular shape of the current access points, but illustrates which is connected in a way which alludes to the wireless activity LED. The point was discussed that the other LED is actually more semantically correct, but not as suitable as an icon.

Additionally, these [http://wiki.laptop.org/go/Image:School_server_and_ap.png alternate designs] were proposed, using antennae to make the purpose of the icons clearer. We may wish to elicit feedback about these alternatives from teachers and kids to see which convey the notion of wireless connectivity the best. The triangle proposed here was used once, and subsequently removed due to some distaste for the shape in this context, but it may still convey the idea better with the antenna. This change is strongly desired for 8.2.

[[Category:Development Team]]
[[Category:Meetings]]

Summer of Code/2009/Groupthink

2009-04-03T04:18:18Z

Bemasc:

{{TOCright}}

====About you====

* What is your name?

Benjamin Schwartz

* What is your email address?

You know my e-mail address; I'm on the mailing list all the time.

* What is your Sugar Labs wiki username?

bemasc

* What is your IRC nickname?

bemasc

* What is your primary language? (We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)

English

* Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)

Cambridge, MA

* Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?

I have worked in open-source before. For example, I am the author of http://dev.laptop.org/git/projects/dobject/

====About your project====

* What is the name of your project?

Decentralized Asynchronous Collision-free Editing with Groupthink

* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

To be blunt: Write is awesome, but not as awesome as it could be. There are three major problems with Write, but really, they're all the same problem. The first problem is that if the initiating user leaves the shared session (or their battery dies or ...), sharing will simply cease. Users may continue to edit, but their edits will not be shared over the network, even though Sugar continues to indicate that it is a shared activity session. The second problem is that Write is not tolerant to network disruptions. If the mesh network divides the group in two pieces for a few minutes, this will destroy the shared session, at least for those who've lost contact with the initiating node. Thirdly, Write provides no mechanism for working independently and then later merging changes. If two students begin editing a report together, then go to their separate homes and keep working, there is no automated way for them to merge their work the next day in school. Instead, they must use "copy and paste" to manually combine the versions.

To solve this problem, I will implement a completely decentralized, asynchronous text editing system. I will do this in [Groupthink http://dev.laptop.org/git/projects/dobject/], using the [StringTree http://dev.laptop.org/git/projects/dobject/tree/groupthink/stringtree.py] data structure that I have already written for the purpose. I still need to write a network serialization format, a disk serialization format, and a widget that is backed by the NetworkedStringTree.

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

Week 1: Write a widget, subclassing gtk.TextArea, that is backed by a StringTree
Week 2: Extend this widget with callbacks that respond correctly when the StringTree is edited by someone else. (This is actually surprisingly difficult to do, and attempts to attack this problem often wind up in fields like [Operational Transformation http://en.wikipedia.org/wiki/Operational_transformation].)
Week 3: Write a network protocol (using Groupthink's existing high-level network system, which runs over Telepathy's D-Bus tubes).
Week 4: Write a simple activity containing the SharedTextArea widget over a SharedStringTree, and stress the system to debug live sharing.
Week 5: Write a disk (i.e. Journal) serialization protocol. Ideally, this would just be the d-bus network protocol, marshaled into a bytestream, but the dbus-python interface doesn't expose marshaling. I wrote [a patch http://bugs.freedesktop.org/show_bug.cgi?id=19723] but demarshaling doesn't work, and smcv's been too busy to help me out with it. Pester smcv.
Week 6: Figure out and implement the journal semantics necessary to allow users to edit things by themselves, then later join a shared session and have their local copy merged into the shared copy. (This may actually already be the case. Test, debug, and submit patches as necessary.)
Week 7: Write documentation. Write a simple test suite. Write a SharedTextAreaWithSyntaxHighlighting and replace the widget in Pippy.

* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

I've already done much of the work, and specifically the hard algorithmic part. I'm knowledgeable about the field, and about algorithms in general, having a degree in Mathematics with Computer Science.

====You and the community====

* If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.

This project will be the first big step for Groupthink. It will establish Groupthink as a way for naive Activity authors to add reliable, robust sharing functionality to their activities just by importing the groupthink library and using the provided widgets and data structures.

* Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?

I live in Cambridge, MA. A nearby deployment would certainly be appropriate, though I'm not sure where. One interesting place is the KIPP school in Lynn, MA. This is a high-intensity charter middle-school for low-income students. I showed them some XOs last year, and they were ecstatic.

* What will you do if you get stuck on your project and your mentor isn't around?

I will continue work as before? I will ask the Gobby people (I found where they hide, and what algorithm they use (it's adOPTed)!).

* How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?

I'll send even more traffic than usual to the mailing list, as I produce code that needs review or testing.

====Miscellaneous====
* We want to make sure that you can set up a [[DevelopmentTeam#Development_systems|development environment]] before the summer starts.
[[Image:Bms_gsoc2009.png|thumb|right|Oh yeah.]]

* What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)

M. American M.

* Describe a great learning experience you had as a child.

When I was about 12 I read Chaos by James Gleick. In the footnotes he had the equation for generating a Mandelbrot fractal. I opened up QuickBasic, started typing, and before long had my first mandelbrot generator. It was super-awesome.

Actually. At first it had a bug, and it took me a long time to figure out. The bug was that I had modified a value and then accessed it again, thinking I was getting the original value. That bug taught me about the need for temporary variables.

* Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more

I'm down with O(L)PC (Yeah you know me!).

[[Category:2009 GSoC applications]]

[[Category:GSoC]]

File:Bms gsoc2009.png

2009-04-03T04:16:42Z

Bemasc: This should probably be deleted once the application process for gsoc2009 is over.

This should probably be deleted once the application process for gsoc2009 is over.

Summer of Code/2009/Groupthink

2009-04-03T04:05:35Z

Bemasc:

{{TOCright}}

====About you====

* What is your name?

Benjamin Schwartz

* What is your email address?

You know my e-mail address; I'm on the mailing list all the time.

* What is your Sugar Labs wiki username?

bemasc

* What is your IRC nickname?

bemasc

* What is your primary language? (We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)

English

* Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)

Cambridge, MA

* Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?

I have worked in open-source before. For example, I am the author of http://dev.laptop.org/git/projects/dobject/

====About your project====

* What is the name of your project?

Decentralized Asynchronous Collision-free Editing with Groupthink

* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

To be blunt: Write is awesome, but not as awesome as it could be. There are three major problems with Write, but really, they're all the same problem. The first problem is that if the initiating user leaves the shared session (or their battery dies or ...), sharing will simply cease. Users may continue to edit, but their edits will not be shared over the network, even though Sugar continues to indicate that it is a shared activity session. The second problem is that Write is not tolerant to network disruptions. If the mesh network divides the group in two pieces for a few minutes, this will destroy the shared session, at least for those who've lost contact with the initiating node. Thirdly, Write provides no mechanism for working independently and then later merging changes. If two students begin editing a report together, then go to their separate homes and keep working, there is no automated way for them to merge their work the next day in school. Instead, they must use "copy and paste" to manually combine the versions.

To solve this problem, I will implement a completely decentralized, asynchronous text editing system. I will do this in [Groupthink http://dev.laptop.org/git/projects/dobject/], using the [StringTree http://dev.laptop.org/git/projects/dobject/tree/groupthink/stringtree.py] data structure that I have already written for the purpose. I still need to write a network serialization format, a disk serialization format, and a widget that is backed by the NetworkedStringTree.

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

Week 1: Write a widget, subclassing gtk.TextArea, that is backed by a StringTree
Week 2: Extend this widget with callbacks that respond correctly when the StringTree is edited by someone else. (This is actually surprisingly difficult to do, and attempts to attack this problem often wind up in fields like [Operational Transformation http://en.wikipedia.org/wiki/Operational_transformation].)
Week 3: Write a network protocol (using Groupthink's existing high-level network system, which runs over Telepathy's D-Bus tubes).
Week 4: Write a simple activity containing the SharedTextArea widget over a SharedStringTree, and stress the system to debug live sharing.
Week 5: Write a disk (i.e. Journal) serialization protocol. Ideally, this would just be the d-bus network protocol, marshaled into a bytestream, but the dbus-python interface doesn't expose marshaling. I wrote [a patch http://bugs.freedesktop.org/show_bug.cgi?id=19723] but demarshaling doesn't work, and smcv's been too busy to help me out with it. Pester smcv.
Week 6: Figure out and implement the journal semantics necessary to allow users to edit things by themselves, then later join a shared session and have their local copy merged into the shared copy. (This may actually already be the case. Test, debug, and submit patches as necessary.)
Week 7: Write documentation. Write a simple test suite. Write a SharedTextAreaWithSyntaxHighlighting and replace the widget in Pippy.

* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

I've already done much of the work, and specifically the hard algorithmic part. I'm knowledgeable about the field, and about algorithms in general, having a degree in Mathematics with Computer Science.

====You and the community====

* If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.

This project will be the first big step for Groupthink. It will establish Groupthink as a way for naive Activity authors to add reliable, robust sharing functionality to their activities just by importing the groupthink library and using the provided widgets and data structures.

* Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?

I live in Cambridge, MA. A nearby deployment would certainly be appropriate, though I'm not sure where. One interesting place is the KIPP school in Lynn, MA. This is a high-intensity charter middle-school for low-income students. I showed them some XOs last year, and they were ecstatic.

* What will you do if you get stuck on your project and your mentor isn't around?

I will continue work as before? I will ask the Gobby people (I found where they hide, and what algorithm they use (it's adOPTed)!).

* How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?

I'll send even more traffic than usual to the mailing list, as I produce code that needs review or testing.

====Miscellaneous====
[[Image:New-developer-challenge.png|thumb|right|An example of the kind of screenshot of your first modification to your development environment which you should include in your application. Note that the drop-down menu text has Mel's email address in place of the word "Restart" - your screenshot should contain your email instead.]]
* We want to make sure that you can set up a [[DevelopmentTeam#Development_systems|development environment]] before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.
* What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)

M. American M.

* Describe a great learning experience you had as a child.

When I was about 12 I read Chaos by James Gleick. In the footnotes he had the equation for generating a Mandelbrot fractal. I opened up QuickBasic, started typing, and before long had my first mandelbrot generator. It was super-awesome.

Actually. At first it had a bug, and it took me a long time to figure out. The bug was that I had modified a value and then accessed it again, thinking I was getting the original value. That bug taught me about the need for temporary variables.

* Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more

I'm down with O(L)PC (Yeah you know me!).

[[Category:2009 GSoC applications]]

[[Category:GSoC]]

Summer of Code/2009/Groupthink

2009-04-03T04:04:20Z

Bemasc: New page: {{TOCright}} ====About you==== # What is your name? Benjamin Schwartz # What is your email address? You know my e-mail address; I'm on the mailing list all the time. # What is your S...

{{TOCright}}

====About you====

# What is your name?

Benjamin Schwartz

# What is your email address?

You know my e-mail address; I'm on the mailing list all the time.

# What is your Sugar Labs wiki username?

bemasc

# What is your IRC nickname?

bemasc

# What is your primary language? (We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)

English

# Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)

Cambridge, MA

# Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?

I have worked in open-source before. For example, I am the author of http://dev.laptop.org/git/projects/dobject/

====About your project====

# What is the name of your project?

Decentralized Asynchronous Collision-free Editing with Groupthink

# Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

To be blunt: Write is awesome, but not as awesome as it could be. There are three major problems with Write, but really, they're all the same problem. The first problem is that if the initiating user leaves the shared session (or their battery dies or ...), sharing will simply cease. Users may continue to edit, but their edits will not be shared over the network, even though Sugar continues to indicate that it is a shared activity session. The second problem is that Write is not tolerant to network disruptions. If the mesh network divides the group in two pieces for a few minutes, this will destroy the shared session, at least for those who've lost contact with the initiating node. Thirdly, Write provides no mechanism for working independently and then later merging changes. If two students begin editing a report together, then go to their separate homes and keep working, there is no automated way for them to merge their work the next day in school. Instead, they must use "copy and paste" to manually combine the versions.

To solve this problem, I will implement a completely decentralized, asynchronous text editing system. I will do this in [Groupthink http://dev.laptop.org/git/projects/dobject/], using the [StringTree http://dev.laptop.org/git/projects/dobject/tree/groupthink/stringtree.py] data structure that I have already written for the purpose. I still need to write a network serialization format, a disk serialization format, and a widget that is backed by the NetworkedStringTree.

# What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

Week 1: Write a widget, subclassing gtk.TextArea, that is backed by a StringTree
Week 2: Extend this widget with callbacks that respond correctly when the StringTree is edited by someone else. (This is actually surprisingly difficult to do, and attempts to attack this problem often wind up in fields like [Operational Transformation http://en.wikipedia.org/wiki/Operational_transformation].)
Week 3: Write a network protocol (using Groupthink's existing high-level network system, which runs over Telepathy's D-Bus tubes).
Week 4: Write a simple activity containing the SharedTextArea widget over a SharedStringTree, and stress the system to debug live sharing.
Week 5: Write a disk (i.e. Journal) serialization protocol. Ideally, this would just be the d-bus network protocol, marshaled into a bytestream, but the dbus-python interface doesn't expose marshaling. I wrote [a patch http://bugs.freedesktop.org/show_bug.cgi?id=19723] but demarshaling doesn't work, and smcv's been too busy to help me out with it. Pester smcv.
Week 6: Figure out and implement the journal semantics necessary to allow users to edit things by themselves, then later join a shared session and have their local copy merged into the shared copy. (This may actually already be the case. Test, debug, and submit patches as necessary.)
Week 7: Write documentation. Write a simple test suite. Write a SharedTextAreaWithSyntaxHighlighting and replace the widget in Pippy.

# Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

I've already done much of the work, and specifically the hard algorithmic part. I'm knowledgeable about the field, and about algorithms in general, having a degree in Mathematics with Computer Science.

====You and the community====

# If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.

This project will be the first big step for Groupthink. It will establish Groupthink as a way for naive Activity authors to add reliable, robust sharing functionality to their activities just by importing the groupthink library and using the provided widgets and data structures.

# Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?

I live in Cambridge, MA. A nearby deployment would certainly be appropriate, though I'm not sure where. One interesting place is the KIPP school in Lynn, MA. This is a high-intensity charter middle-school for low-income students. I showed them some XOs last year, and they were ecstatic.

# What will you do if you get stuck on your project and your mentor isn't around?

I will continue work as before? I will ask the Gobby people (I found where they hide, and what algorithm they use (it's adOPTed)!).

# How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?

I'll send even more traffic than usual to the mailing list, as I produce code that needs review or testing.

====Miscellaneous====
[[Image:New-developer-challenge.png|thumb|right|An example of the kind of screenshot of your first modification to your development environment which you should include in your application. Note that the drop-down menu text has Mel's email address in place of the word "Restart" - your screenshot should contain your email instead.]]
# We want to make sure that you can set up a [[DevelopmentTeam#Development_systems|development environment]] before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.
# What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)

M. American M.

# Describe a great learning experience you had as a child.

When I was about 12 I read Chaos by James Gleick. In the footnotes he had the equation for generating a Mandelbrot fractal. I opened up QuickBasic, started typing, and before long had my first mandelbrot generator. It was super-awesome.

Actually. At first it had a bug, and it took me a long time to figure out. The bug was that I had modified a value and then accessed it again, thinking I was getting the original value. That bug taught me about the need for temporary variables.

# Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more

I'm down with O(L)PC (Yeah you know me!).

[[Category:2009 GSoC applications]]

[[Category:GSoC]]

0.84/Ideas

2008-10-16T13:47:08Z

Bemasc: /* Glucose */

== Glucose ==

* Implement the source key feature for sugar (i.e. add a modal alert like the objectchooser with a filetree on the left and a non-editable gtksourceview on the right)
* [http://dev.laptop.org/ticket/7911 #7911] Integrate speech synthesis. '''(erikos, hemantg)'''
* Implement grab/scroll key #447 (erikg?)
* Incrementally remove PS functionality in favour of implementing Buddy and Activity directly in Sugar toolkit, opening the way to use other unmodified Telepathy backends and clients.
* Make it possible to subscribe to users ("add friends") who you can't see through the server and/or find via Gadget. This means making JIDs human readable, letting the user discover their own JID, providing a way to type them in, and getting the user to approve incoming friend requests.
* Autosave more intelligently. Currently, Activities are autosaved on every "context switch", which makes many things slow. We should add a "dirty bit" so that Activities only get saved when something has changed, and autosave at most once every N minutes.

== Telepathy ==
* Implement peer-to-peer connections in Telepathy Gabble so that one-to-one tube data doesn't go via the XMPP server. Big performance/reliability wins.

== Control panel ==

* Make layout language 'independent' using hippo http://dev.laptop.org/ticket/8148
* Add section to set the keyboard layout #6780
* Add section for the speech settings
* Better use of localization in the language and date&time section #8312
* Get rid of the modify_bg hacks and get this into the theme

== Journal ==

* Add start-with option to the entry palette. This is useful in the main view of the journal but as well in the [http://wiki.laptop.org/go/Image:Activity_management-07.jpeg home view activity management]. Use cases are for example the opening of a web-page source in either write or browse without having to reveal the entry's detail view.
* Add filter functionality to objectchooser. For example when adding an image into Write the objectchooser should only provide the caller with images [http://dev.laptop.org/ticket/3060 #3060].
* The activity palette in the home view should allow to resume recent journal entries. [http://wiki.laptop.org/go/Image:Activity_management-07.jpeg Mockup].
* Encourage to title entries
* [http://dev.laptop.org/ticket/6128 #6128] Organization with tags.
* File sharing. Implement [http://monkey.collabora.co.uk/telepathy-spec.git_file-transfer/ file transfer] [http://people.collabora.co.uk/~jonny/spec.html#org.freedesktop.Telepathy.Channel.Type.FileTransfer.DRAFT (HTML)] for gabble. Implement the UI for file transfer in the Sugar UI ([http://wiki.laptop.org/go/Specifications/Object_Transfers Object Transfer]).
* Add a Portfolio Activity that children use to select key Journal entries. The Portfolio activity would let them sequence and annotate the entries to make a multimedia presentation of their work.

== Browse ==
* palette option to download linked file #2903
* object chooser and download alert in the right window #7498

== Read ==
* Improved relationship between ebook mode and collaboration #7017 #6537 #6538 #6645 #6736
* Push evince changes upstream

== Chat ==
* Switch UI to GTK to enable text selection #8472
* Wrap as a widget for use in other activities (Andres Ambrois)

== Write ==
* Elect new master for collaboration when the sharer leaves #3445
* Colored backgrounds for edits by different participants, as per mockups on [http://wiki.laptop.org/go/Write Write]
* Use one-to-one tubes such as stream tubes when doing any bulk transfers (if they get implemented as P2P; see below).

0.82/Roadmap

2008-05-17T17:21:18Z

Bemasc: Attempt taxonomy conversion, partially (suggested by Marco)

== Schedule ==

{| cellpadding="10" cellspacing="0" border="1"
!Date
!Task
!Notes
|-
|May 8 2008
|Development start
|New features proposal
|-
|May 21
|Sugar 0.81.1 Tarballs Due
|
|-
|May 22
|Sugar 0.81.1 Development Release
|
|-
|June 5
|Sugar 0.81.2 Tarballs Due
|
|-
|June 6
|Sugar 0.81.2 Development Release
|
|-
|June 19
|Sugar 0.81.3 Tarballs Due
|
|-
|June 20
|Sugar 0.82 Beta 1 (0.81.3)
|Feature, ABI, String freeze
|-
|July 7
|Sugar 0.81.4 Tarballs Due
|
|-
|July 8
|Sugar 0.82 Beta 2 (0.81.4)
|
|-
|July 21
|Sugar 0.81.5 Tarballs Due
|
|-
|July 22
|Sugar 0.82 Release Candidate 1 (0.81.5)
|
|-
|July 31
|Sugar 0.81.6 Tarballs Due
|
|-
|August 1
|Sugar 0.82 Release Candidate 2 (0.81.6)
|Hard Code Freeze
|-
|August 7
|Sugar 0.82 Tarballs Due
|
|-
|August 8
|Sugar 0.82 Final Release!
|
|}

== Glucose Modules ==

* [[Modules#sugar|sugar]]
* [[Modules#sugar-base|sugar-base]]
* [[Modules#sugar-datastore|sugar-datastore]]
* [[Modules#sugar-presence-service|sugar-presence-service]]
* [[Modules#sugar-toolkit|sugar-toolkit]]
* [[Modules#sugar-artwork|sugar-artwork]]
* [[Modules#journal-activity|journal-activity]]

== Fructose Modules ==
* [[Modules#chat-activity|chat-activity]]
* [[Modules#web-activity|web-activity]]
* [[Modules#read-activity|read-activity]]
* [[Modules#log-activity|log-activity]]
* [[Modules#write-activity|write-activity]]
* [[Modules#calculate-activity|calculate-activity]]
* [[Modules#terminal-activity|terminal-activity]]
* [[Modules#tamtam-activity|tamtam-activity]]

== Glucose Dependencies ==

* hippo-canvas
* telepathy-glib
* telepathy-gabble
* telepathy-salut
* telepathy-python

== Tickets ==

* [http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&component=datastore&component=presence-service&component=datastore&component=journal-activity&order=priority&milestone=Update.2&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=keywords Glucose tickets] on laptop.org

== New features ==

[[Category:Developer]]