Dave Noha writes:
> > My modest proposal is that these activities be encapsulated
> > in actual "strategy" objects that perform each function.
> > Then, once a message has arrived and been parsed out of its
> > raw format, it is simply passed to the list of strategies.
> > Other strategies can be included as needed, so
>
> How is this functionally different from replacing your
> Freenet.message classes with other implementations?
I believe his point was (please correct me if I`m wrong) that
subclassing was not a very good mechanism for the kind of
delegation he`s talking about. I agree, with the caveat that I
haven`t looked at the Request class in depth with this idea in
mind.
Very well said, Dave. The point is not to make the functionality
different, at least at this step. The point is to make it easier to
later change the functionality, either by changing a few lines of Java
code or maybe just tweaking the .freenetrc.
Replacing Freenet.message.* in my examples would be a real waste. The
examples want all that functionality, they just want to add a little
more, and add it in a way that is easily found and understood (instead
of spreading it across all the new message classes -- classes which
would largely be duplicates of the originals).
In general, I think it would improve the appeal of running a
Freenet node if multiple intelligent strategies were available
to select from for managing the data store, bandwidth, access,
etc. E.g., a bandwidth cap is nice...
I'm not sure my proposal makes adding a bandwidth cap any easier, but
I'm willing to be proved wrong.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
