Re: [VOTE] Accept Wave into the incubator

[Christopher Brind]

+1 (non-binding)

On 30 November 2010 06:52, Dan Peterson  wrote:

> Hi everyone,
>
> Please vote on the acceptance of Wave into the Apache incubator.
>
> The proposal is available at:
> http://wiki.apache.org/incubator/WaveProposal
> (for your convenience, a snapshot is also copied below)
>
> The earlier discussion thread can be found at:
>
> http://apache.markmail.org/message/3ebtccdxvipp2732?q=general%40incubator.apache.org+list:org.apache.incubator.general+order:date-backward&page=2
>
> The vote options:
>
> [ ] +1 Accept Wave for incubation
> [ ] +0 Don't care
> [ ] -1 Reject for the following reason:
>
> The vote is open for 72 hours.
>
> Thanks,
> -Dan
>
> Apache Wave Proposal (Apache Incubator)
>
> = Abstract =
>
> Apache Wave is the project where wave technology is developed at Apache.
> Wave in a Box (WIAB) is the name of the main product at the moment, which
> is
> a server that hosts and federates waves, supports extensive APIs, and
> provides a rich web client. This project also includes an implementation of
> the Wave Federation protocol, to enable federated collaboration systems
> (such as multiple interoperable Wave In a Box instances).
>
> = Proposal =
>
> A wave is a hosted, live, concurrent data structure for rich communication.
> It can be used like email, chat, or a document.
>
> WIAB is a server that hosts waves. The best analogy for this is a mail
> server with a web client. WIAB is comprised of a few high-level components:
> the client and the server. They have the following major functionality
> (though this is not an exhaustive list):
>
>  * Client
>  *A dynamic web client for users to create, edit, and search waves. Users
> can access this client by directly visiting the server in a browser.
>  * Gadgets provide the ability to insert, view, and modify the UI --
> exposing the Wave Gadgets API (
> http://code.google.com/apis/wave/extensions/gadgets/guide.html)
>  * A console client that can create and edit waves via a command-line-like
> interface.
>  * Server
>  * Hosts and stores waves. WIAB comes with a default storage mechanism. The
> administrators of the server may configure it to use alternative storage
> mechanisms.
>  * Indexing, allowing for searching the waves a user has access to.
>  * Basic authentication, configurable to delegate to other systems.
>  * Federation, allowing separate Wave in a Box servers to communicate with
> each other using the Wave Federation Protocol (
> http://www.waveprotocol.org/federation).
>  * Robots, using the Wave Robots API, (
> http://code.google.com/apis/wave/extensions/robots/) may interact with
> waves
> on a WIAB instance.
>
> = Background =
>
> Wave expresses a new metaphor for communication: hosted conversations. This
> was created by Lars and Jens Rasmussen after observation of people's use of
> many separate forms of communication to get something done, e.g, email,
> chat, docs, blogs, twitter, etc.
>
> The vision has always been to better the way people communicate and
> collaborate. Building open protocols and sharing code available in an open
> and free way is a critical part of that vision. Anyone should be able to
> bring up their own wave server and communicate with others (much like
> SMTP).
>
> We hope this project will allow everyone to easily gain the benefits of
> Wave
> with a standard implementation of Wave – in a box.
>
> = Rationale =
>
> Wave has shown it excels at small group collaboration when hosted by
> Google.
> Although Wave will not continue as a standalone Google product, there is a
> lot of interest from many organizations in both running Wave and building
> upon the technology for new products.
>
> We are confident that with the community-centric development environment
> fostered by the Apache Software Foundation, WIAB will thrive.
>
> = Initial Goals =
>
> The initial goals of the project are:
>
>  1.  To migrate the codebase from code.google.com and integrate the
> project
> with the ASF infrastructure (issue management, build, project site, etc).
>  1.  To quickly reach a state where it is possible to continue the
> development of the Wave In a Box implementation under the ASF project.
>  1.  To add new committers to the project and grow the community in "The
> Apache Way".
>
> = Current Status =
>
> The open source Wave in a Box project has existed in various forms for
> approximately 16 months (starting out life as the FedOne open source
> project).
>
> FedOne began in July 2009 in order to accelerate adoption of the wave
> federation protocol, and serve as a proof of concept that a non-Google
> implementation of the wave federation protocol could interoperate with the
> Google production instance. It worked. FedOne's existence lead to a
> prototype by Novell that demonstrated federation between Google Wave and
> Novell Pulse (now known as Vibe). In addition, in May of 2010, SAP unveiled
> a prototype version of SAP StreamWork that federated with both Novell Pulse
> and Google Wave. All three syste

Re: JavaHL package namespace / migration / compatability

[Christopher Brind]

I can understand why Subversion should be made a top level project quickly,
but I personally believe the namespace change is a reasonable request in
order to graduate for all the same reasons that convinced me Pivot should
change its namespace.

It sends the wrong message not to change given the importance of the Apache
namespace, imho.

Regards,
Chris

On 18 Nov 2009 05:18, "Brett Porter"  wrote:

On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote: > On Wed, Nov 18, 2009 at
12:06 AM, Justin Erenkr...
Handling case by case is valuable.

If it were com.somecompany.foo.* then there might be cause for concern in
that it might not appear independent.

I'm fine with Subversion keeping the current namespace, under the
understanding that migrating in the future in a way that makes sense for
their users is a good thing to do. This is similar to when a subproject goes
TLP too - for example, I work on Archiva, which came from Maven, which is
partially org.apache.maven.archiva.* and partially org.apache.archiva.*.

- Brett

- To
unsubscribe, e-mail: genera...

Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

[Christopher Brind]

Hi,

I have read through the proposal and I like the idea of it.

The only issues I have are around modularity and shell/console.  Apache
already has a modularity solution (Felix) based on an open standard (OSGi) I
don't think the Java community as a whole needs yet another modularity
solution. =)   Felix also provides a shell which allows you to manage module
(bundle) lifecycle (install, start, stop, update, uninstall) and while I
don't know what the status is regarding the 'Standard Shell' (OSGi RFC 132)
it is quite easy to add new commands to the Felix shell.   Felix is also
very lightweight, so it wouldn't add much to your footprint, but would give
you a sophisticated dynamic module contain in which to work as well as
making it compatible with various environments already using OSGi now (e.g.
Application Servers, etc).

I could see potential uses for this project in my own work, but as I've
implied, it would have to be compatible with OSGi which is where I spend
most of my time.  I'd even offer to assist that effort on this project.

This is more of a question, is there any Java API standard abstraction for
chat protocols?  e.g. javax.chat?  I don't think there is but there is of
course JMS, is ChatterBot significantly different from JMS?  If so, perhaps
a low priority side goal of the project should be to develop a standard Java
API standardisation for chat?

Cheers,
Chris


On 29 January 2010 03:32, Donald Whytock  wrote:

> Hello all...
>
> As discussed before, here is the current wiki text of the proposal for
> Chatterbot, a lightweight framework for chat responders.  The proposal
> is at
>
> http://wiki.apache.org/incubator/ChatterbotProposal
>
> Interested in comments, feedback and participation.
>
> Thanks...
>
> Don
>
> - wiki text -
>
> Abstract
>
> ChatterBot is a lightweight, multiprotocol framework and container for
> chat responders.
>
> Proposal
>
> ChatterBot is a framework for developing chat responders (applications
> that respond to messages received via online chat) and a container for
> deploying them. It is written in Java SE, and runs as a Java
> application. Chat responders are built by extending a single class and
> modifying a configuration file to reference the new class.
> ChatterBot's focus is on the following characteristics:
>
> - Small: The current framework consists of eight core classes.
>
> - Standalone: ChatterBot does not require external servers to operate.
>
> - Portable: ChatterBot should work as run from any Java-capable
> machine. For full functionality that machine should have internet
> access, but localhost and console connectivity are possible. It should
> be possible to run multiple instances of ChatterBot on the same
> machine or on separate machines with no loss of functionality.
>
> - Extensible: An instance of ChatterBot can support multiple message
> parsers and protocols. Adding more is done by editing a configuration
> file.
>
> - Dynamic: Activating and de-activating modules should be possible
> during runtime.
> Multi-user access: Multiple users, over multiple protocols, should be
> able to access deployed applications.
>
> Rationale
>
> A chat responder can serve as a user interface to applications, either
> those built into the responder or external applications with which the
> responder communicates. Such an interface is more secure than
> interfaces such as Telnet or web services since it does not require
> open ports in the firewall; the container connects out through the
> firewall to the chat server, rather than allowing users to connect in.
>
> A lightweight chat responder can be installed on any system to allow
> command-line access to users over whatever protocol a user may have
> access to. Thus applications can be accessed from web interfaces,
> instant-message systems, text messages, email, etc. A scalable
> container can allow as many or as few access protocols as are desired.
>
> ChatterBot, therefore, has value for those circumstances where a user
> interface is needed but a server-based or enterprise solution is
> either not possible or not desired. It also can serve as a bridge
> between applications, where one or more uses a chat protocol such as
> XMPP to communicate.
>
> Background
>
> ChatterBot began in 2005 as a thin-server approach to online
> multi-user board games, implemented as applets sending gamestate
> changes to one another via message relaying. The idea was to make as
> general-purpose a server as possible, so that multiple games could be
> built that employed the same message-relaying system.
>
> Version 0.2 of the server was then refined in 2008 to allow for more
> varied and functional message-handlers, and was used to implement a
> room system that allowed for room-specific applications -- parsers
> that checked the user's room before handling a command and sent
> responses to other room occupants. This version was structured
> entirely around XMPP. The global namespace was introduced to allow
> modules to com

Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

[Christopher Brind]

Sorry for shaking things up, but it sounds like you got the gist of things.
 Using OSGi services to wire up Chatterbot makes it much more flexible in
the long run allowing developers/users to plug in alternative
implementations of things if they want to.  I'm quite happy to join your
project as a committer to help guide this if you wish. :)

Not sure about the proposal side of things, I'm sure someone will pipe up
soon enough.

Cheers,
Chris

On 1 February 2010 18:39, Donald Whytock  wrote:

> I had originally thought that Felix Shell would replace Chatterbot
> Listener, but I no longer think so.  Felix Shell, as far as I can
> tell, is focused around Commands that have single outputs directed
> toward their originator; Chatterbot Parsers, in a multiuser
> environment, might have multiple outputs, and therefore have to
> respond in the context of the originator. (v0.2 had writeMsg(target,
> message) as well as writeMsgToAllBut(target, message).)  On the other
> hand, I can see a Parser that acts like a Remote Shell.
>
> So at this point we're talking about changing the proposal to focus on:
>
> - Building Chatterbot around Felix as a modularity framework, with its
> lifecycle management, its ServiceEvents to resolve dependencies, and
> its Service properties to cut down on global datastore space.
>
> - Building protocol handlers around a more general-purpose interface,
> so that they can be used elseproject, then wrapping bundles around
> them to make them standard services in a Felix environment for
> Chatterbot.
>
> I think Listener and Sender have to remain, rebuilt as services.
> Changes to make Parser a service should leave the parse() method
> functionally unchanged.
>
> The global datastore (I call it the "namespace" in the proposal; I see
> now that that conflicts with a term of art) would work best as a
> service.  I'd like to discuss the Chatterbot Listable class vs. the
> standard Dictionary or HashTable classes; Listable allows access to
> subsets of the datastore by using a partial key.
>
> So where do I go from here?  A new proposal draft?
>
> Don
>
> On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall 
> wrote:
> > On 1/29/10 10:38, Donald Whytock wrote:
> >>
> >> I have an overview of the current Chatterbot architecture at
> >>
> >> http://www.imtower.net/chatterbot/doku.php?id=overview
> >>
> >> Chatterbot is different from JMS inasmuch as it's currently built to
> >> receive messages from chat IDs and turn them into messages from
> >> Chatterbot-internal IDs, and vice versa.  My intent was to allow
> >> multiple chat IDs (same protocol or different protocols) to translate
> >> into a single Chatterbot ID, so that a user could choose how he
> >> accessed the bot.  Which protocol a message comes in over should be
> >> totally transparent to the Parsers, and the Parsers should be able to
> >> send messages out using Chatterbot IDs and not worry what protocol is
> >> used to deliver them.
> >>
> >> Looking briefly over Felix (http://felix.apache.org), I'd say the
> >> Chatterbot Listener and Parsers would be equivalent to the Felix Shell
> >> and Commands, if the Shell was fed a JMS stream consolidated from
> >> multiple message streams, and if its output was then dispersed over
> >> multple message streams.  Though there would also need to be a way to
> >> set up a Command to respond to any input string, rather than one
> >> starting with a particular word.
> >>
> >
> > Just to be clear, there are two shells at Felix:
> >
> >http://felix.apache.org/site/apache-felix-shell.html
> >
> > And
> >
> >http://felix.apache.org/site/apache-felix-gogo.html
> >
> > Although they basically do the same thing, I think Christopher was
> referring
> > to the latter shell, which is more sophisticated than the former and may
> > eventually become and OSGi standard.
> >
> > -> richard
> >
> >> Chatterbot Parsers also have the capacity to originate messages to
> >> users other than the one whose message the Parsers are responding to,
> >> so that they can serve as chatrooms; this would be the equivalent of
> >> Felix sending out notifications to other users when a given user
> >> performed a command.  Would this compare to Felix Event Admin?
> >>
> >> That pretty much just leaves the global namespace, which is
> >> essentially volatile JDO.  This is where the Chatterbot IDs are stored
> >> and the Modules are defined; it gets updated by Channels, and can be
> >> r

Re: Interest in Android-based projects?

[Christopher Brind]

I dare say I would probably be interested in most anything you can come up
with :) but I suspect the project would need to be something more specific
as a starter for the incubator?

Could throw out a few ideas maybe, see what people can come up with?  Is
this mailing list the right place for that discussion?

Cheers,
Chris



On 15 February 2010 20:56, Noel J. Bergman  wrote:

> Would there be interest in a project to develop Android-based apps?
>
> know that it sounds like an umbrella, and perhaps it would be until we
> developed some critical mass, but it would provide us with a place to
> collaborate.
>
>--- Noel
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Boot strapping Android projects @ Apache

[Christopher Brind]

+1 :)

Cheers,
Chris


On 9 November 2010 15:13, Noel J. Bergman  wrote:

> About a half dozen or so of us met up at ApacheCon after the lightning
> talks
> to talk briefly about Android @ the ASF.
>
> The proposal is to create an android-inter...@i.a.o (we also thought about
> @labs, but the general consenus seemed to be the Incubator due to some of
> the Labs' restrictions, which we think are good restrictions).
>
> We want to encourage others working on Android-related code to share
> experience and existence with their fellow Committers.  For example, did
> you
> know that Felix & Aries already work with Android?  What else does?  What
> else should?  Etc.
>
> In other words, we want to provide a gathering point for all of the people
> working in isolation -- to provide a meeting place for those intersted in
> expanding Android-based activity at the ASF.  It is not so much an umbrella
> as a vital nexus, and breeding ground for importing or creating projects,
> which would then stand on their own.
>
>--- Noel
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: OODT release appearing in mirrors

[Christopher Brind]

All the mirror pages for me except for the last FTP one worked for me.  In
the case of the last one the whole domain times-out.

Clicking on a random link on each page didn't yield any 404s for me.

Maybe you have a problem your end, or with a proxy or something?

Cheers,
Chris



On 10 November 2010 18:20, Mattmann, Chris A (388J) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Hi Guys,
>
> I'm not seeing our OODT release hit the mirrors as quick as it normally
> does. For example, going here:
>
> http://www.apache.org/dyn/closer.cgi/incubator/oodt
>
> Yields many 404s. There are one or 2 that don't, but most do. It's been
> quite a few days since the tarballs were copied to
> people.a.o:/www/www.apache.org/dist/incubator/oodt
>
> ls -al
> total 15242
> drwxr-sr-x   2 woollard  incubator 8 Nov  7 23:55 .
> drwxrwsr-x  30 apbackup  incubator32 Nov  9 17:40 ..
> -rw-r--r--   1 woollard  incubator  3067 Nov  7 23:54
> CHANGES-0.1-incubating.txt
> -rw-r--r--   1 woollard  incubator  9380 Nov  7 23:54
> KEYS-0.1-incubating.txt
> -rw-r--r--   1 woollard  incubator  15527021 Nov  7 23:55
> apache-oodt-0.1-incubating-src.tar.gz
> -rw-r--r--   1 woollard  incubator   833 Nov  7 23:55
> apache-oodt-0.1-incubating-src.tar.gz.asc
> -rw-r--r--   1 woollard  incubator79 Nov  7 23:55
> apache-oodt-0.1-incubating-src.tar.gz.md5
> -rw-r--r--   1 woollard  incubator86 Nov  7 23:55
> apache-oodt-0.1-incubating-src.tar.gz.sha1
>
> Also, looking at:
>
> http://www.apache.org/dist/incubator/
>
> I don't see an OODT folder there. Are we doing something wrong?
>
> Cheers,
> Chris
>
>
> ++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.mattm...@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] OODT Graduation to TLP

[Christopher Brind]

Is it still the case that Dave Kale is still the only non JPL committer
(other than mentors)?

Cheers,
Chris





On 11 November 2010 15:18, Mattmann, Chris A (388J) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Hi IPMC'ers and the rest of the Incubator community,
>
> The OODT community has been discussing graduation to TLP [1]. There is
> overwhelming consensus in the community (all +1 VOTEs including those from
> our mentors) that we've achieved what's required here in the Incubator, and
> so we'd like to put forth the following board resolution for the next Board
> meeting to promote OODT to an Apache TLP and graduate from the Incubator.
>
> Please VOTE on the below resolution for promoting OODT to an Apache TLP and
> graduating from the Incubator. The VOTE is open for 72 hrs.
>
> [ ] +1 Accept OODT's graduation from the Incubator
> [ ] +0 Don't care.
> [ ] -1 Don't accept OODT's graduation from the Incubator because...
>
> =
>  Establish the Apache OODT Project
>
>   WHEREAS, the Board of Directors deems it to be in the best
>   interests of the Foundation and consistent with the
>   Foundation's purpose to establish a Project Management
>   Committee charged with the creation and maintenance of
>   open-source software related to the construction of scientific,
>  data management systems for distribution at no charge to the public.
>
>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>   Committee (PMC), to be known as the "Apache OODT Project",
>   be and hereby is established pursuant to Bylaws of the
>   Foundation; and be it further
>
>   RESOLVED, that the Apache OODT Project be and hereby is
>   responsible for the creation and maintenance of software
>   related to the construction of scientific, data management
>  systems; and be it further
>
>   RESOLVED, that the office of "Vice President, Apache OODT" be
>   and hereby is created, the person holding such office to
>   serve at the direction of the Board of Directors as the chair
>   of the Apache OODT Project, and to have primary responsibility
>   for management of the projects within the scope of
>   responsibility of the Apache OODT Project; and be it further
>
>   RESOLVED, that the persons listed immediately below be and
>   hereby are appointed to serve as the initial members of the
>   Apache OODT Project:
>
>  * Andrew Hart (ah...@apache.org)
>  * Brian Foster (bfos...@apache.org)
>  * Cameron Goodale (good...@apache.org)
>   * Chris A. Mattmann (mattm...@apache.org)
>  * Dan Crichton (crich...@apache.org)
>   * David Kale (davek...@apache.org)
>  * David Woollard (wooll...@apache.org)
>  * Ian Holsman (i...@apache.org)
>  * Joshua Garcia (joshu...@apache.org)
>  * Justin Erenkrantz (jerenkra...@apache.org)
>  * Paul Ramirez (prami...@apache.org)
>  * Sean Hardman (shard...@apache.org)
>  * Sean McCleese (smccl...@apache.org)
>  * Sean Kelly (ke...@apache.org)
>
>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Chris A. Mattmann
>   be appointed to the office of Vice President, Apache OODT, to
>   serve in accordance with and subject to the direction of the
>   Board of Directors and the Bylaws of the Foundation until
>   death, resignation, retirement, removal or disqualification,
>   or until a successor is appointed; and be it further
>
>   RESOLVED, that the Apache OODT Project be and hereby
>   is tasked with the migration and rationalization of the Apache
>   Incubator OODT sub-project; and be it further
>
>   RESOLVED, that all responsibilities pertaining to the Apache
>   Incubator OODT sub-project encumbered upon the
>   Apache Incubator Project are hereafter discharged.
> =
>
> Here's my +1 (binding).
>
> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.mattm...@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

ip-clearance voting

[Christopher Brind]

Hi,

I've been following gene...@incubator for a while and have a question.

When there's a vote on ip-clearance why would one vote against it?
 Presumably one would only vote against it if someone knows some reason why
the codebase cannot be accept for legal reasons, and not for any technical
reason, is that correct?

Thanks in advance.

Cheers,
Chris

Re: [IP-CLEARANCE] Bushel Donation to Apache Ant

[Christopher Brind]

Apologies if this is not the place to discuss this, but I notice on the
Bushel Google Code page that it only honours "require-bundle", is that still
the case?

Are there plans to support import/export package soon (since package level
dependencies are the recommended practice and, IMHO, require-bundle is
frankly an after-thought to OSGi to support the Eclipse crowd).  I think
this has the potential to be a great addition to Ivy, but not until it
supports package level dependencies.

That said, I don't have anything against this happening, just curious and
would like to know that further development is planned. :)

Cheers,
Chris



On 15 November 2010 12:14, Stefan Bodewig  wrote:

> Hi all,
>
> the people behind the Bushel project at Google Code[1] which provides
> limited OSGi support to Apache Ivy want to donate their codebase for
> integration into Ivy.
>
> The code can be found at JIRA issue IVY-1241[2], all three authors
> (one of them is Ant PMC member Nicolas Lalevée) signed software grants
> and the Ant PMC voted to accept the donation.
>
> The form is already online at
>  but I forgot to
> add it to the index (done now, should become world-visible soonish).
>
> 72hrs waiting period for -1s start now.
>
> Thanks
>
>Stefan
>
> [1] http://code.google.com/p/bushel/
>
> [2] https://issues.apache.org/jira/browse/IVY-1241
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Accept Wave for incubation

[Christopher Brind]

+1 (non binding) loved wave, glad it's not going to die!

On Tuesday, November 23, 2010, Dan Peterson  wrote:
> Hello all,
>
> We'd like to propose Wave for entry into the ASF incubator.
>
> The draft proposal is available at:
> http://wiki.apache.org/incubator/WaveProposal
> (for your convenience, a snapshot is also copied below)
>
> A wave is a hosted, live, concurrent data structure for rich communication.
> It can be used like email, chat, or a document. Wave in a Box (WIAB) is the
> name of the main product at the moment, which is a server that hosts and
> federates waves, supports extensive APIs, and provides a rich web client.
> This project also includes an implementation of the Wave Federation
> protocol, to enable federated collaboration systems (such as multiple
> interoperable Wave In a Box instances).
>
> As a result of the recent Wave Summit, beyond growing a few new committers,
> we've put together the following proposal for migrating the community into
> the ASF incubator. More details on the summit & Wave in a Box progress in
> this blogpost:
> http://googlewavedev.blogspot.com/2010/11/this-weeks-wave-protocol-summit-updates.html
>
> We are looking forward to your feedback and suggestions.
>
> By the way, if you're looking to learn more about the technology related to
> wave, you can see the videos and presentations from the recent Wave Summit
> in: https://wave.google.com/wave/waveref/googlewave.com/w+rwFyiw47A
>
> Kind regards,
> -Dan, on behalf of the Wave Community
>
> P.S. For those on the wave-protocol Google Group (that aren't yet on
> general@incubator.apache.org), please participate in this discussion
> by sending a message to general-subscribe at incubator dot apache dot org
>
>
> Apache Wave Proposal (Apache Incubator)
>
> = Abstract =
>
> Apache Wave is the project where wave technology is developed at Apache.
> Wave in a Box (WIAB) is the name of the main product at the moment, which is
> a server that hosts and federates waves, supports extensive APIs, and
> provides a rich web client. This project also includes an implementation of
> the Wave Federation protocol, to enable federated collaboration systems
> (such as multiple interoperable Wave In a Box instances).
>
> = Proposal =
>
> A wave is a hosted, live, concurrent data structure for rich communication.
> It can be used like email, chat, or a document.
>
> WIAB is a server that hosts waves. The best analogy for this is a mail
> server with a web client. WIAB is comprised of a few high-level components:
> the client and the server. They have the following major functionality
> (though this is not an exhaustive list):
>
>  * Client
>   *A dynamic web client for users to create, edit, and search waves. Users
> can access this client by directly visiting the server in a browser.
>   * Gadgets provide the ability to insert, view, and modify the UI --
> exposing the Wave Gadgets API (
> http://code.google.com/apis/wave/extensions/gadgets/guide.html)
>   * A console client that can create and edit waves via a command-line-like
> interface.
>  * Server
>   * Hosts and stores waves. WIAB comes with a default storage mechanism. The
> administrators of the server may configure it to use alternative storage
> mechanisms.
>   * Indexing, allowing for searching the waves a user has access to.
>   * Basic authentication, configurable to delegate to other systems.
>   * Federation, allowing separate Wave in a Box servers to communicate with
> each other using the Wave Federation Protocol (
> http://www.waveprotocol.org/federation).
>   * Robots, using the Wave Robots API, (
> http://code.google.com/apis/wave/extensions/robots/) may interact with waves
> on a WIAB instance.
>
> = Background =
>
> Wave expresses a new metaphor for communication: hosted conversations. This
> was created by Lars and Jens Rasmussen after observation of people's use of
> many separate forms of communication to get something done, e.g, email,
> chat, docs, blogs, twitter, etc.
>
> The vision has always been to better the way people communicate and
> collaborate. Building open protocols and sharing code available in an open
> and free way is a critical part of that vision. Anyone should be able to
> bring up their own wave server and communicate with others (much like SMTP).
>
> We hope this project will allow everyone to easily gain the benefits of Wave
> with a standard implementation of Wave – in a box.
>
> = Rationale =
>
> Wave has shown it excels at small group collaboration when hosted by Google.
> Although Wave will not continue as a standalone Google product, there is a
> lot of interest from many organizations in both running Wave and building
> upon the technology for new products.
>
> We are confident that with the community-centric development environment
> fostered by the Apache Software Foundation, WIAB will thrive.
>
> = Initial Goals =
>
> The initial goals of the project are:
>
>  1.  To migrate the codebase from code.google.com and integrate