As Torbon points out, there are a lot of different level's of complexity. The complexity I was speaking of, was integration. i.e. in order to use WFP, a company need to either (1) integration OT into there message infrastructure and develop their own OT-based editor (if the Google one is no longer actively developed), or (2) do an OT-plain text/XML translation error which breaks some of the guarantees that you have by using OT. Both these increase the work needed to implement WFP.
Ian Roughley Pulse Platform Architect On 08/07/2010 11:52 AM, Torben Weis wrote: > I think there are different kinds of complexity and only one is really a > problem for "uptake". > > 1) It is complex to install > This is usually only the case because nobody invested the time in a good > packaging. It just needs doing and can be fixed later. > > 2) It is complex inside > This is a problem in attracting more core developers. If the project is > sexy enough, some few excellent programmers will take up the challenge. > Most open source programmers commit code to the "surrounding" code base > or fix obvious mistakes. Only few people are required to maintain the > algorithmic core, which can be as complex as necessary without killing > the project. > > 3) It is complex outside > This is the real killer. To make the project successful you need dozens > of auxiliary projects, i.e. notifiers, gadgets, full-fledged clients > for Win/Linux/Mac/iPhone/Windows Phone ... you name it. You want > existing apps to integrate wave etc. Currently most of these auxiliary > projects need to implement OT, protobuf, the wave document model, etc. > This is COMPLEX. Few people will do this. > > Having a Java implementation is not helpful in general. Many projects > are built on different languages. An OT-lib written in portable C/C++ > might be a good idea, because it can be wrapped by ruby, python etc. > This lib must encapsulate the complexity. It does not matter how complex > it is on the inside. > > Another option is to provide a REST-like interface for the client/server > protocol which can be used without OT. You could still read all wave > content, you could even create new blips. You just cannot edit a blip > concurrently. We need an upgrade path that allows developers to connect > to wave using standard tools such as HTTP/JSON/XML. If they like it and > users ask for more, it is likely that developers will upgrade to OT to > allow for even better collaboration. > > Here is a rule of thumb: An open source programmer should be able to > connect to wave and exchange some data during a weekend hack (in an > ideal case without relying on any wave specific libraries). If the first > encounter with wave programming takes longer, many programmers will turn > away. > > Greetings > Torben > > 2010/8/7 Dave butlerdi <[email protected] <mailto:[email protected]>> > > People here seem to be worried about uptake. I think that in the > very short period that the protocol > has been available that there has been fantastic uptake especially > when one considers the state of the > project last year. > > At present SAP, Salesforce.com, Novel, processWave and many more > have invested considerable effort > and have produced some impressive results. > > If complexity were a true problem then Hadoop and the related > projects would not have been so successful > as they can be very complex. > > It would seem as though a framework where the various components > could be a bit more modular would > be a good approach...But these are all things that could be > considered during an incubation and general > consultation period. > > I know that we have invested considerable time and resource to > integrating portions of this project and have in > fact based some of our EU funding on these activities. We will move > forward with the integration as going back is > really not an attractive option. > > > > > > -- > 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] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:wave-protocol%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > -- > --------------------------- > Prof. Torben Weis > Universitaet Duisburg-Essen > [email protected] <mailto:[email protected]> > > -- > 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.
