Here is something I had started working on before I heard about wave. The idea is contextual stream-oriented computing (I'm using these applications to get a task done, not just to be using them). The first prototype<http://tinyurl.com/whatisflow>I did was a simple browser that represented my browsing history as a graph and each page visited as a node in that graph. Going beyond that the idea was to allow for the graph to be shared for collaboration and to go beyond just web browsing to include documents, emails, instant message conversations, everything that had to do with a task would be navigable using the graph.
Shortly after I developed the prototype, Adaptive path presented a concept video of a browser of the future <http://adaptivepath.com/aurora/>. While their video was much more polished than my design. A lot of the concepts that I had for flow were demonstrated in their vision. I pitched the idea to some VC people and they shot it down saying that it's suicide to try to enter the browser market space. They couldn't see past the POC to what I really wanted to produce. Unfortunately, I had to shelve the concept until I had the means to finance its development. And then I saw the announcement of Wave. It was basically the embodiment of what I envisioned. I think a client like "Flow" with Wave on the backend, would be incredible. I've started a project on Codeplex <http://flow.codeplex.com> for the software. If anyone is interested in joining my efforts, let me know. On Tue, Dec 22, 2009 at 8:41 AM, Aldon Hynes <[email protected]>wrote: > Sounds good to me. You want to build a prototype you can share with the > list? > > Depending on the language you like, you might want to try building > something > in Java, using the example console client that comes with FedOne. Or, you > might want to use the QT/C++ code that is part of QWaveclient. (I've been > testing that a little bit on my Nokia N900, looks very promising). Or, you > might want to use the Ruby code that Dan set up as part of his Ruby on > Sails > project (Dan, you still around? Got any updates?) > > The other thing that I'm interested in is other ways of interacting. For > example, could I build an XMPP gateway so that waves show up as XMPP > conversations? You would lose some of the neat features that way, but it > would make accessible in a bunch of interesting new ways. I've had the > same > thought about accessing Waves via IMAP. > > Then, of course, there is the idea of Wave-Virtual World connectivity. > I've > been very interested in Wave-Second Life interconnectivity, as well as > possibly interconnectivity with projects like OpenSim or OpenCobalt. I > believe both already have some XMPP functionality built in, so it might be > a > very interesting project to work on. (Extra points goes to the student > that > builds a Wave Server that runs in OpenSim or OpenCobalt). > > Random thoughts for now, > Aldon > http://www.orient-lodge.com/wave > > -----Original Message----- > From: [email protected] > [mailto:[email protected]]on Behalf Of x00 > Sent: Tuesday, December 22, 2009 7:29 AM > To: Wave Protocol > Subject: Gadget like client interfaces. > > > Forgive me if I have posted this in the wrong place > > I see federation working in terms of data, however I can think of one > key idea disrupting the true potential of federation. That is > differences in client interfaces. > > This is because conceivably one particular solution say an enterprise > solution, might want to represent things differently for a particular > application. There is no reason why a wave has to be represented like > wavelets and blips are now (conversation like). Obviously things like > flat style waves are fairly trivial, but this is not necessarily > sharing the wave as intended. > > I think it is natural that a conversation is attached to what you are > doing. However if what you are doing is working on a specific thing, > rather than just being a dialogue, I would want the specific thing and > its interface to the focus of the wave and not the conversation (I > still support the idea of having gadgets in blips). > > This is because if we want to work on a document we want to work on a > document. I don’t want it remotely bridged it a haphazard way through > robots, similarly I doesn’t make much sense to have it imbedded in a > blip. > > So personally I would say lead by example. Instead of a fixed > interface have the client environment with a default interface that > gracefully erodes, and you get to choose your interface for a wave > which would be a bit like a gadget. You would have access to the wave > conversation > > Example would be working on google docs through wave, say on a > spreadsheet. > > It is also a solution to the embed API. You wouldn’t need to duplicate > data with robots, simply have an agent that acts a bridge, and style > appropriately. The API would allow you to choose your interface, and > which aspects of the environment you want exposed. > > Security concerns are the same as they are now, it comes down to > education at the end of the day. > > -- > > 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%[email protected]> > . > 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%[email protected]> > . > 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.
