I'd like to contribute in this discussion since I used FedOne in a thesis
for building a collaborative editor for graphical process plans. For this,
I also needed to store non text data in federated Wave conversation
elements. What I did at that time was using ADTs included in the FedOne
code base.
I strongly agree with you Davide.
I particularly disagree with the idea of dropping Wave APIs! The opposite
is the case for me. There should be a nice API(s) for using core Wave
features for building custom federated real-time collaborative applications
(rather than cloning the code base and hacki
protobuf module in the main build. The
> >> protocol buffer source would get generated and then compiled in every
> >> build. Everyone working on wave in a box would need to have the protoc
> >> compile installed even if they aren't working on the protocol buffers.
&g
ut working with the code base.
> >> > - Poetnetially slows the evolution of a scalable architecture that
> >> delivers
> >> > what the community is asking for.
> >> >
> >> >
> >> > 2) Ditch the current code base and start new.
> >> >
> >> > Pros:
> >> > -
> >> > - We can design something that meets the community needs.
> >> > - We can simply the design from the beginning.
> >> >
> >> > Cons:
> >> > -
> >> > - We are very close to a release, this approach would set back future
> >> > releases.
> >> >
> >> >
> >> > 3) Keep the current code base AND start a new one.
> >> >
> >> > Pros:
> >> > -
> >> > - Can keep driving through the apache process.
> >> > - We still have a working product.
> >> > - We can start the redesign now.
> >> >
> >> > Cons:
> >> > -
> >> > - We barely have enough developers to maintain the current codebase.
> >> > - If interest in the new codebase takes off, existing codebase would
> >> > atrophy.
> >> >
> >> >
> >> > Comments please. Thanks.
> >> >
> >> > ~Michael
> >> >
> >> >
> >>
>
--
Andreas Horst
Heinrichsallee 21, 52062 Aachen
+49 170 4162251
