-----Original Message-----
  From: wave-protocol@googlegroups.com
[mailto:wave-protocol@googlegroups.com]On Behalf Of Dan Peterson
  Sent: Tuesday, November 10, 2009 11:06 PM
  To: wave-protocol@googlegroups.com
  Subject: Re: Google Wave Federation Protocol port open on WaveSandbox.com
and Other Updates

  Hey Aldon,

  There have been several different efforts in the Drupal and wave space:

  Drupal waves: How to add a Google Wave to a fresh Drupal installation.
    a.. http://wave-samples-gallery.appspot.com/about_app?app_id=18009
  Google Wave Drupal Integration: A Drupal module and corresponding robot
that enabled the embedding of Google Waves
    a.. http://wave-samples-gallery.appspot.com/about_app?app_id=18013
    b..
http://googlewavedev.blogspot.com/2009/08/prototyping-drupal-module-f...
le.html
  Drubot: A Robot for posting wave to a drupal site.
    a.. http://wave-samples-gallery.appspot.com/about_app?app_id=36020
  Cheers,
  -Dan

  On Wed, Nov 4, 2009 at 2:10 PM, Aldon Hynes <Aldon.Hy...@orient-lodge.com>
wrote:

    As a quick response, the blog posts I've been writing and posting on
    http://www.orient-lodge.com are all in Drupal
    I'm using this server for hosting quite a few Drupal sites, as well as
Elgg,
    Joomla, Laconi.ca, probably wordpress and who knows what else.

    It is the same site that I'm running my Openfire XMPP server and the
Fedone
    server.

    Setting up FedOne on a server running Drupal is really no different than
on
    any other server.

    I should also note that I'm running on a VPS server.  Setting up FedOne
on a
    shared host probably just isn't possible, and would probably violate ToS
for
    most shared hosting services.  I sure wouldn't want to try.

    I should also note that laconi.ca is written in PHP and makes extensive
use
    of XMPP.  I'm pretty sure it uses XMPPHP.  I hope to do some
    laconi.ca/FedOne testing when my FedOne instance is a little more
stable.

    As to connecting all of this to Drupal, my thoughts are that Drupal
    developers should be looking more at Google Gadgets than at Federated
    servers.  In particular, I think Drupal developers should be paying
    attention to Shindig and the Drupal Shindig shim as a means of working
with
    gadgets, but that is just my thinking at this point.

    Has anyone on this list done anything interesting with Shindig, Gadgets,
    Drupal, or some combination of the three?

    Enough for now.

    Aldon

    -----Original Message-----
    From: wave-protocol@googlegroups.com

    [mailto:wave-protocol@googlegroups.com]On Behalf Of Kipp
    Sent: Tuesday, November 03, 2009 7:33 PM
    To: Wave Protocol
    Subject: Re: Google Wave Federation Protocol port open on
    WaveSandbox.com and Other Updates

    For anyone who may be interested, I've written an article describing
    my thoughts, from the perspective of a Drupal developer, about this
    announcement of the opening of the federation port at WaveSandBox at
    http://sites.google.com/site/federationprototypeserver/.

    Ciao for now,

    Kipp

    On Nov 2, 1:18 pm, Dan Peterson <dpeter...@google.com> wrote:
    > Hi everyone,

    > Just a little bit ago we opened the federation port for Google Wave's
    > developer instance, so we can all begin experimenting with federating
    waves
    > against WaveSandbox <http://wavesandbox.com/>.com
    <http://wavesandbox.com/>.
    > Since that is the developer preview instance, please keep in mind that
it
    is
    > an experimental service, and it is likely that there will be
unforeseen
    > glitches in the coming weeks. Please share your progress here in the
    > wave-protocol forum, so we can work through issues together.

    > Over the next several weeks we plan to add some important features to
this
    > service:

    >    - TLS for XMPP:
    >       - The protocol itself specifies two distinct security
mechanisms:
    >       delta signing and XMPP over TLS. Delta signing is required to be
    able to
    >       verify the authenticity of the source of the operations. TLS is
an
    >       additional layer of security to the XMPP protocol, but it can be
    > a bit hairy
    >       to configure. In order to encourage prototyping, TLS is not
enabled
    on
    >       WaveSandbox.com, but it will become required in the coming
    > weeks. This gives
    >       existing FedOne instances an opportunity to get signed
certificates
    and
    >       configure their XMPP servers properly.
    >    - Reliable Delivery:
    >       - For any communication mechanism it is important that there is
a
    >       contract for delivery of the message contents, and we are
working on
    a
    >       reliable delivery mechanism from WaveSandbox.com.

    > With that said, to get started federating with WaveSandbox.com, you
should
    > visit the wave-protocol project
<http://code.google.com/p/wave-protocol/>
    and
    > review the installation

instructions<http://code.google.com/p/wave-protocol/wiki/Installation>.
    > If you have previously installed and configured FedOne to talk to
    > other FedOne instances, you will need to upgrade to the latest
revision
    > (revision 08b5eecb93) to properly interoperate with WaveSandbox.com.
For
    > those of you building your own clients or servers, please take special
    care
    > to review the documentation that describes the

errata<http://code.google.com/p/wave-protocol/wiki/DifferencesFromSpecificat
    ...>
    > between
    > the protocol specification and the current FedOne implementation
between
    the
    > protocol specification and the current FedOne implementation, and
    > coincidentally, WaveSandbox.com.

    > If you don't have a WaveSandbox.com account, you may request a
developer
    > account here <https://services.google.com/fb/forms/wavesignupfordev/>.
We
    > hope to provision those accounts within a week or so.

    > As you are developing, please keep in mind we welcome contributions to
the
    > growing open source reference implementation; please check out this
guide
    > on submitting open source
    > code<http://code.google.com/p/wave-protocol/wiki/SubmittingCode>
    > .

    > On the specification front, the Google Wave Conversation Model draft
    > specification has been revised and updated to include the blip
document
    > schema, which defines the representation of rich text necessary for
proper
    > interoperation with WaveSandbox.com. That document is available

here:http://www.waveprotocol.org/draft-protocol-specs/wave-conversation-mode
    l

    > The updated specifications and FedOne code introduce new changes to
the
    wave
    > model, but they aren't the last; we expect more changes to come as we
    > iterate with you on the implementation and learn from these early
    > experiments in federation. Once the specifications and reference code
have
    > converged and become reasonably stable we will begin to federate
    > wave.google.com, until then we have a lot of work to do. Looking
forward
    to
    > hearing your feedback.

    > Cheers,
    > -Dan

> On Tue, Nov 3, 2009 at 7:59 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1

>> On 11/2/09 11:18 AM, Dan Peterson wrote:

>>>     * Reliable Delivery:
>>>           o For any communication mechanism it is important that there
>>>             is a contract for delivery of the message contents, and we
>>>             are working on a reliable delivery mechanism
>>>             from WaveSandbox.com.
>> What is meant by "reliable delivery"? What are your requirements for a
>> reliable delivery mechanism? I ask because the broader XMPP developer
>> community has put a lot of thought into this problem, and depending on
>> your needs a solution might already exist. Let's not reinvent the wheel
>> if we don't need to. :)

>> Peter

> Hi Peter,

> We're still working through some of the finer points on "reliable
> delivery", we're also hoping to incorporate some form of flow control.
> We have yet to write a full spec of how we envision this mechanism to
> work, so if you allow be to be brief, we expect the requirements for
> "reliable delivery" to be:
> - short term retransmission and acknowledgement of all messages (this
> can be done using regular XMPP mechanisms).
> - selectively dropping non-essential messages queued for
> retransmission if there are any non-trivial transmission delays (e.g.
> delta updates, which can be recovered by a receiver using getHistory
> on receipt of a commit notification).
> - keeping retransmission efficient by only sending of essential
> messages over a significant amount of time (e.g. days, weeks,....
> months? if a wave provider has gone offline. The retransmission policy
> might be similar to what happens with SMTP (*)). Essential messages
> would include the last commit notification for all wavelets on which a
> provider has users.

> (*) One might possibly add an active mechanism on the receiver's part
> to query for new waves, however there are a few issues with this. e.g
> after being down for a long while, receivers can't know the complete
> set of servers to contact for waves without some central authority
> informing a provider which providers have waves for whom.