Vick, (et al), It sounds like your idea of a Wave-IMAP client is very similar to what I was thinking about. Here are some thoughts about what it might look like:
Take probey and rewrite it to listen for Imap commands on an appropriate imap port, instead of for http commands on the port specified in the configuration. Currently, probey logins in as probey (or some other preconfigured value). This would be changed to log in with the username passed in authentication. A new option would need to be added to retrieve available waves. I believe this would be something like calling getIndexWave. From this perspective, each wave would be represented as a message in an IMAP folder. So, the IMAP command to get messages in a folder would call this new option. When a message is opened in an imap client, the imap agent would translate that to what probey does for its getblips processing now, and the result would be returned as the 'email' message to the imap client. Effectively, this would make a wave server an imap server. To push this a little bit further, an SMTP agent would also probably be a good thing. The SMTP agent would listen on an SMTP port and when an email message comes in, it would create it as a wave, with the receipient as a participant in the wave. If the sender is also on the wave server, they could be added as a participant. Thus, an email into the wave server via an SMTP agent would end up being available to a user connecting to an IMAP agent for the emails they are receiving. This would all be the simple part. Where it would become more interesting and challenging would be having replies modify existing waves, adding the reply part as a new blip, instead of creating a new wave. However, that could be a phase two part. Does this make sense? What other ideas do people have? Aldon -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of ?? ? Sent: Thursday, January 28, 2010 11:57 AM To: Wave Protocol Subject: Re: Gadget like client interfaces. Hi Aldon, This is Vick, a MSc student from Imperial College London. I am very interested in the idea of "accessing Waves via IMAP", and I am thinking about doing a similar research for my postgraduate project, like to build a Wave-IMAP server to pass waves through IMAP to the user client, e.g. Thunderbird. Could you explain a bit detail to me? Like how could we pass waves through IMAP? Maybe we need a Wave-IMAP gateway server, which implements federation protocol to communicate other wave servers and opens an IMAP interface to the email client, so that the webpage-based waves are embedded in the MIME-based IMAP messages to the user client? Thanks a lot. Vick On Dec 22 2009, 1:41 pm, "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, > Aldonhttp://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 athttp://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. -- 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.
