Wim, I'll be documenting exactly how the private user-data wavelet works later this week. If you need more information sooner, then feel free to ask.
-David On Nov 28, 4:05 pm, Nemo157 <[email protected]> wrote: > This actually touches on some of the things I've been thinking about > recently. As well as having a strongly defined client-server protocol what > we also need is a defined metadata format / "client-client" protocol. The > format of the private wavelet containing information on which blips are read > and unread should be well specified so that someone utilising various > clients is able to keep things such as unread status constant across all > their clients. This would involve: > > 1. Finding the private wavelet. > 2. Decoding the data stored in it. > 3. Well defined fallbacks for missing data and/or unsupported extensions. > > If my current project actually progresses over the summer I'll probably > have a lot more to say on this subject in a few months. > > -- > Wim > > On Sun, Nov 28, 2010 at 5:02 PM, Michael MacFadden < > > > > > > > > [email protected]> wrote: > > I think if we get the infrastructure right, we can support many > > different kinds of user interfaces. I think there are some challenges > > of course but a scenario where the core components could be reused as > > building blocks from which to compose / customize / and skinned would > > be great. > > > I think the question becomes how these customizations happen. If we > > had a strong client-server protocol (not saying we don't, I just don't > > know at this point) then the packaging of a new ui could be completely > > separate from the WiaB distribution. The other alternative woud be to > > have some sort of plugin architecture that would allow skinned or > > customized UIs to be deployed with in wave in the box. Not sure what > > the right path is. > > > Currently most of the reusable stuff for the WiaB client is ultimately > > provided through GWT. In other worse the javascript APIs come from > > compiled GWT. I am wondering if the GWT compiled APIs can be > > leveraged by raw HTML / CSS/ Javascript apps? > > > There are already people asking about leveraging the client-server > > protocol for other web apps or even desktop and/or mobile apps. If we > > draw a correlation to email protocols then I think what we have is > > something like: > > > Federation Protocol ~= SMTP > > Client Server Protocol ~= IMAP / POP > > > I think it is widely understood that the federation protocol needs to > > be robust and standardized. I am not so sure the client server > > protocol is viewed in the same way. At the moment, it is viewed by > > some as specific to the client / sever implementation pair. I haven't > > heard to much talk about a single server supporting many different > > clients through a standard protocol. This is apparent in the fact > > that we don't even have a real name for the protocol (i.e. we just > > call it client-server, vs server-server which we call Federation). > > > I will start a wiki page where we can start tracking some of these > > issue and objectives and where people can post their mockups and > > ideas. > > > Michael > > > On Nov 27, 8:04 pm, Kai Chang <[email protected]> wrote: > > > Pictures definitely work for some applications. Re-reading the "generic" > > > comment earlier, I think the implication was GWave tried to be a > > > Jack-of-all-Trades. It could kind of do many, many things. But it > > wasn't a > > > great document editor, or social network, or micro-blog, or wiki, or > > project > > > management tool, etc. > > > > Wikipedia describes GWave as: "*a web-based computing platform and > > > communications protocol, designed to merge key features of media like > > > e-mail, instant messaging, wikis, and social networking*." > > > > The underlying protocol has great advantages for all these applications. > > > > However, creating a single interface that fuses all these "features" and > > > maintains its own conceptual integrity may not be feasible. > > > > On Sat, Nov 27, 2010 at 3:41 PM, Gamer_Z. <[email protected]> wrote: > > > > I personally liked the idea of using someone's picture. It seems to > > > > make sense, dragging someone's head to a wave to bring him or her to > > > > the discussion. > > > > > Also, I agree that the use of GWT is the one of the biggest problems > > > > (at least for me). I am glad to create mockups in HTML+CSS, but I do > > > > not understand GWT. > > > > > On Nov 27, 6:24 pm, Kai Chang <[email protected]> wrote: > > > > > A wiki is a great idea. Then we could tackle many disparate > > problems, > > > > and > > > > > start grouping similar ideas together into a coherent interface. > > > > > > I don't feel wave.google.com had a generic interface. It was > > strongly > > > > > influenced by Gmail/Facebook, and threaded comments like Reddit. > > Profile > > > > > pics, for instance, are used in at least four contexts: Contact > > list, > > > > Wave > > > > > Inbox, at the top of a wave (participants list), and within a wave. > > So > > > > you > > > > > can easily be looking at a screen in Gwave where you see the same pic > > 4 > > > > > times. To me, that screams Facebook. > > > > > > One thing I would like to see is more designer/developer friendly > > tools > > > > for > > > > > creating and modifying the interface. Torben's Wala-compiler is > > headed > > > > in > > > > > the right direction. Java/GWT is an incredibly high barrier to entry > > for > > > > UI > > > > > designers. > > > > > > I'm interested in creating HTML/CSS/JS mockups of design ideas. > > Still > > > > > working on Tensor, which is a study in tree structures and contextual > > > > blips > > > > > (eg, an issue tracker wavelet where blips are tasks). > > > > > > Ideally, WIAB should eventually ship with multiple skins/interfaces. > > > > These > > > > > should serve as starting points of different interface paradigms for > > > > people > > > > > looking to customize WIAB. > > > > > > Also, slightly too specific, how feasible would a Wiki-like two > > column > > > > > revision history be to build? GWave's Playback was cool, but not > > very > > > > > practical for reviewing groups of changes. > > > > > > On Sat, Nov 27, 2010 at 1:54 PM, Michael MacFadden < > > > > > > [email protected]> wrote: > > > > > > Again I agree completely. Maybe I should set up a wiki page where > > > > > > people can most mock ups and ideas for us to discuss. As I said I > > > > > > think the more diverse ideas we can look at, the better off we will > > > > > > be. > > > > > > > Michael > > > > > > > On Nov 27, 2:23 pm, x00 <[email protected]> wrote: > > > > > > > Figure out aims (already started), project initial user base, get > > UI > > > > > > > people on board, don't be limited by gwt, look into methods of > > > > hooking > > > > > > > up interfaces, schematics, schematics, mockups, etc. > > > > > > > > *more detail* > > > > > > > > Wave is kind of user centric at the moment. I know it sounds > > > > > > > contradictory making a user interface other than user centric. > > But it > > > > > > > isn't about making it less user friendly, on the contrary, more > > bout > > > > > > > striking the balance between task and the users (which obviously > > are > > > > > > > an important part of getting the task done). I created a > > schematic > > > > for > > > > > > > an interface that was more task centric, and it was actually like > > a > > > > > > > walk-through experience (wave agnostic). It is too specific for > > WAIB, > > > > > > > but the general idea that social media for the sake of social > > media, > > > > > > > whilst good for reaping personal information, is ultimately not > > > > > > > uniquely useful to the users other than status reasons, whereas > > > > things > > > > > > > like wave are about getting things done and communicating ideas > > > > > > > collaboratively. Obviously there are other synonyms for "task" > > but > > > > you > > > > > > > get the idea. I think architecture that reflects the aim to > > > > > > > collaborate on something makes sense. > > > > > > > > I know I said this before, but I'll say it again. “Conversation” > > is > > > > > > > just a default communication. It is one type of collaborative > > > > > > > communication amongst many possibilities. Granted it will be a > > > > popular > > > > > > > one that would be used along side app doc and other things. > > However > > > > > > > it would be good in the long term to build all models and their > > > > > > > interfaces with api for that. > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > > > "Wave Protocol" group. > > > > > > To post to this group, send email to > > [email protected]. > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected]<wave-protocol%2bunsubscr...@goog > > > > > > legroups.com> > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > > > . > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/wave-protocol?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Wave Protocol" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]<wave-protocol%2bunsubscr...@goog > > > > legroups.com> > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/wave-protocol?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
