Oops, I forgot to mention option 3 which is also preferred and the easiest
one:
Option 3: To remove the whole IndexWave and ConsoleClient related code
without fixing it.
The suggested patch is actually related to the option 3, not to the option
2.
2011/8/21 Yuri Z vega...@gmail.com
Hello
The
Option 3 sounds good.
Cleaner the core code is the better for understanding.
Id guess as a new client/server protocol is implemented it might be
tempting to build a really basic (code-independent) client for testing
though.
On 21 August 2011 16:54, Michael MacFadden michael.macfad...@gmail.com
I'm in strong support of option 3 to remove the whole IndexWave and
ConsoleClient related code. They served us well in the early days of
experimentation with federation but now it's holding us back. The
IndexWave design doesn't work and it will require a major investment,
which we cannot afford,
Option 3 gets a +1 from me.
It would be great to restore the ConsoleClient at some stage - it's a nice
lightweight client, it helps to ensure a sound protocol, and it should be a
useful reference implementation. But if nobody has the time to maintain it
right now, then it's better to focus on
Once a new c/s is established it would make sense to have a simplist
as possible example client, and that could possibly take the form of a
console one.
When that stage comes will there be much advantage in reusing the old
console client code? or is the bulk of the tricky stuff just in the
c/s
