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]. 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.
