On Nov 15, 1:16 pm, Wijnand Wiersma <[email protected]> wrote:
> Op 15 nov 2009, om 16:47 heeft Daniel Danopia het volgende geschreven:
>
>
>
> >> A few questions:
> >> * Do you really think using a SQL database is the right kind of
> >> storage for waves? I think using MongoDB will help you scale the wave
> >> server a lot more.
> > My planned storage method for deltas is to just store the delta's
> > ProtoBuffer representation. Deltas don't change so this should be
> > fine. I will hopefully be able to cache some form of the wave's most
> > recent delta so it won't have to step through every operation on
> > restart.
>
> I don't think this scales well enough.
> You will have to deal with lots and lots of records.
> And yes, always storing the latest version with all deltas applied seems like
> a good idea.
>
> I have been thinking about designing a Wave server and I thought about the
> following:
> * persistent storage in MongoDB.
> * redis as temporary storage (in order to share data between multiple wave
> servers within a cluster, offloading to separate daemons and caching)
>
I'm trying to keep my dependency list low. The only non-standard gem
it requires is thin, but many advanced Rails/Rack users already have
that. My temporary storage is the central Provider that's on xmpp, it
has it all in RAM.
> >> * Isn't it a better idea to use the same client <-> server protocol as
> >> Google uses?
> > It's not really official yet. IIRC there's no actual client/server
> > protocol whitepapers. Hopefully they use something better. In the
> > meantime, I used DRb because it's nice for prototyping - I don't have
> > to worry about client/server a bit, as DRb lets me interact with the
> > server as if it's in the same Ruby instance. Because DRb is modular, I
> > could also set up a server that connects to DRb and seres the FedOne
> > protocol. Too bad FedOne doesn't allow auth, or I would do that.
> > (Maybe a special wave asking you for your password before it servers
> > any others?)
>
> That is indeed a bit of a problem, I was just wondering if you tried to do
> some reverse engineering ;-)
> I hope Google comes up with a formalized C2S spec soon.
>
> Still a shame in my opinion the C2S part is not XMPP based.
I was going to write an adapter to have Sails serve client connections
like a FedOne but decided that it's not worth it, as FedOne's C/S
could completely change any time now.
>
>
>
> >> * Is it possible to extract some gems out of the codebase to make it
> >> more modular/reusable or is the entire codebase too coupled?
> > Yes. In fact, I am in the process of pulling out my ProtoBuffer class
> > into a gem. Beyond that, though, there isn't too much that can be
> > done... maybe an OT gem.
>
> A OT gem would be a kick ass start!
> Separating it in a gem should also make it easier write tests and update.
The issue is that I'm not very good at gem-writing, my ProtoBuffer gem
is the first one I ever did. It also happens to be the only class I
planned to separate from the beginning. All the other code is
intertwined in the Sails module.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
