On Wed, Sep 2, 2009 at 18:06, Fernando Padilla<[email protected]> wrote: > Right. The idea is that you should have methods and returns be as low as > possible ( Iterable ), instead of higher requirements ( Collection, List, > Set, etc ). This just gives you some flexibility on how to implement > things, and reduce the number of data structures you have to maintain or > even iterate through. It's really neat. But like you said, it's > theoretically more efficient, and maybe a good programming practice, but I > don't have any hard numbers.. > > I just wanted to make sure to mention it early, because it might be one of > those things that's easy to bake in, but a little hard to apply later ( > since it changes lots of apis ).. > > But you can look at Google Collections. They have some nice utilities under > the Iterables class, for filtering or transforming the stream of objects in > flight. :)
Maybe you can provide an example how this might look like for the forwarding case to many JIDs? It could improve the API. > ps - But ultimately the memory footprint for most cases won't be an issue. > But I'm really interested in streamlining the code as much as possible > because my use case is for sports fans following a live game ( play by play, > chat, etc ), so there might be a large number of MUC room participants or > PubSub subscribers (thousands? tens of thousands?) And the system simply > can't load up full lists room participants or subscribers to be effective.. I see. This is a valid concern. You'd need a stream instead of a list. > So I'm thinking into the future :) > > Heck I'm already pondering how you can make Vysper cluster aware. It might > be stable enough to start to bake in clustering/sharding concepts.. not sure > if anyone else would be interested in chatting on this. :) +1, that gets me very excited, I'd love to talk more about this. (But please give new topics it's own thread on the list.) Bernd
