On 11/29/09 6:47 AM, Mickaël Rémond wrote: > Hello, > > Le 29 nov. 2009 à 01:53, ThomasWrobel a écrit : > >> Read only access maybe could be accessible without a true login for >> previewing wave data (I feel public wave data could one day be >> quite a resource, just as wikis are today). For any user-specific >> stuff I don't think a login is a problem. After all, isnt this all >> analogous to Pop3/Imap? I don't think people will have much problem >> using their password with clients. > > Twitter shows that client ecosystem can be diverse and play various > roles. I expect that many clients will be developed for wave, some > with very specific purpose (notification of wave update, wave reader, > etc). Some will be web based, some will be desktop base. If your wave > account is only link to wave it might be acceptable to share it. If > your wave account however is linked to a larger system it might be a > problem. Sharing your Google login and password with a web wave > client for example can grant access to many service and not only wave > (wave, email, adwords, etc).
Agreed. There will be many ways to access the same data + service. >> Incidental, I got nothing against XMPP one way or the other. But >> the Pygowave guys now have their Json (/STOMP) c/s protocol up and >> running. They even have a standalone client almost ready. So for >> people wanting to dive in with their own clients, that seems the >> place to go. > > We have also written clients using XMPP, talking to our own wave > server and I would feel XMPP is the way to go because it is extremely > similar to the federation protocol. XMPP client can thus process what > is coming from the client and in the same way, without server side > transformation what is coming through federated wave server. It makes > sense to me. Makes sense to me, too. Now we just need to get to work. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
