Difference between revisions of "Marketing Team/Events/Sugarcamp Boston 2008/Minutes"
| Line 88: | Line 88: | ||
--------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ||
| − | + | Architectural Issues | Sync. Collab | |
------ | (working together) | ------ | (working together) | ||
| Abiword - bemasc | | Abiword - bemasc | ||
Revision as of 09:50, 19 November 2008
Presence Scalability
XS scenario
- Search based interface (Morgan Collett)
- Shrink memory footprint (Martin Langoff)
- ODBC ejabberd roaster
- Web based interface for group management
- ejabberd (seems) a convincing implementation (so far)
- ejabberd is very tweakable, configurable, extensible
- Martin working on it, ready in 6-7 weeks?
Global scenario
- Optional feature (privacy, nat, bandwidth...)
- Jabber server buried in remote control panel
- Must restart Sugar to change
eBook reader (Chris Rowe, Bernie, Martin Langoff)
- OLE Nepal asked for an application for opening, reading and browsing PDF books
- OLE Nepal uses a web-based interface to browse for content
- Martin: there are plenty of custom protocols and formats for content librararies
- Martin: the Internet is already a good enough search tool for content
- Chris: 85% of content is PDF, the rest is mostly MSWord
- Chris: OLE Nepal said: "short term, we just want a viewer + some metadata"
- How should the content be delivered to the kid? USB stick? School server? Online library?
- MStone: you can run a web server on the XO!
Collaboration Brainstorm
- Gadget replaces presence service, and should solve scalability problems caused by the shared roster
- Gadget is an XMPP add on component, should be compatible with any standards compliant server
- Telepathy API is adding avatars, file transfer and P2P tubes.
- It was decided to talk about collaboration requirements Tuesday night.
- Future improvement to telepathy include jingle support, multi user audio video chat, and GeoLocation
- The presence service is being removed
* It is an additional abstraction on top of telepathy, and telepathy is already and abstraction API
- Mission Control provides API to manage accounts(usernames, passwords etc)
* Executes applications based on incoming connections * Sets avatar, manages capabilities, could re-use existing IM account
- A way needs to be found to allow chat in shared activities.
Remarks:
There were two major threads in the conversation: some people decompose the problem into "finding content" and "consuming content" whereas others view these as a seamless action that occurs across multiple sessions; the latter group is primarily concerned with the ergonomics of the complete interaction.
Next, we spent some time trying to agree on a deployment scenario: some people were most interested in guided in-core content-usage scenarios whereas others were most interested in unguided server- or cloud-based content usage scenarios.
We debated whether the Journal should be extended to be a universal portal (with pluggable data layouts) or whether we should rely on disjoint screens for each content acquisition and consumption scenario. We paid particular attention to the question of whether remote/local and past/present/future opportunities should be displayed concurrently. (No consensus was reached.)
We seem to be in agreement that people want to look into the future as well as the past. It seems that we use similar UIs for doing this, so with careful problem decomposition, we should be able to share lots of code.
The closing remarks considered resource allocation: perhaps we should try hardest to adapt an existing dominant solution (e.g. Moodle) to work better in Sugar's deployment scenarios. (Specific technologies that were also considered as examples of the UIs we like include Miro, Calibre, Banshee, Eben's Journal designs, and the ICDL website.)
(Finally, the ergonomics crowd wishes to reiterate that workflows are the central -- the reader and the writer need to fully interoperate and they need to be *slick*.)
Notes from Tuesday Night Collaboration Architecture Discussion
---------------------------------------------------------------------------------------------------
Architectural Issues | Sync. Collab
------ | (working together)
| Abiword - bemasc
0. Physical -- QOS, BW, channels | Tubes/dbus - ???
1. Basic Connectivity | VNCViewer, remote X, MPX - cscott,mstone
2. Mesh AP ---- user ---- user | bespoke protocols for games - bjordan
| IM/chat - morgs,cassidy
| VOIP/Video - cjb
Failure, Programmability, Legacy |
--------------------------------------------------
3. Discovery -- Who Exists?
4. Connectivity -- Who can I talk with? | Async. Collab
5. Presence -- What's happening? | File push / pull - erikg, cscott
6. Meaning -- Let's share.... | Workflow (cms) - Bryan, Eben
| Moodle - Martin
| Email - UY?
Peers/Superpeers | Google docs -
| Web - Eben
Naming / Routing
Split Networks --------------------------------------------------
Interop
Pseudonyms |
Security |
Platform agnosticism / Stubs |
---------------------------------------------------------------------------------------------------