My take on scaling

[hrothgar]

A quadratic equation takes the general form A*(X^2) + B(X) + C =0, with A not equal to zero.

 

From the brief description that you are providing it appears that:

 

The number of updates being generated is a function of the number of systems that "generate" updates and the number of systems that need to receive updates.

 

It is very reasonable to assume that this would result in "load" being a quadratic function of the number of end users. However, as you've noted this can produce a number of problems. Most notably there is some boundary point at which a relatively small increase in the number of end users can produce horrific effects on the total system load.

 

There are three "classic" solutions to this type of problem, both of which are being explored in these threads.

 

1.Parallelize the system, ensuring that none of the sub-components ever approaches critical mass. (Equally significantly, some care must be given to ensure that failures can't “cascade” across sub-components)

2.Architecture the system with sufficient resource that the load never approaches the boundary condition.

3.Architect the system such that the load is no longer a quadratic function.

 

Normally, I have a strong bias in favor of massive parallel architectures. All other things being equally, I'd much rather have a system designed with 10 small, independent systems rather than one large devices. With this said and done, from my perspective, the network effects are sufficiently important that I would prefer to explore a combination of solution 2 and 3...

 

First things first: I just logged into BBO. There are approximately 4560 people connected at this point in time. Of these, I only “care” about the location of 15 individuals (I have 8 friends who are logged on. In theory, I might want to know where the 7 yellows are located) Equally significant, only 48 of those 4560 people can be displayed on my screen at any given point in time. I'd guess that you can realize enormous load savings with minimal impact on end users simply by redesigning the main lobby.

 

In the past, I've argued that the main lobby doesn't serve any real purpose. From my perspective, life would be much easier if the main lobby were partitioned into a series of specialized lobby, each of which is specialized for a different purpose:

 

1. Lobby 1 is similar in nature to the current main lobby, however, it only provides me with a listing of my friends and “Stars”. While the load created by lobby 1 is still a quadratic, is a much “friendlier” one.

2. Lobby 2 allows me to quickly find a partner or a table at which I can play bridge

3. Lobby 3 supports the “Bottoms-up” matching system for teams games

4. Lobby 4 supports Vugraphs

 

Please note: I'm not suggesting that the lobbies that I am describing are either necessary or sufficient. I'm merely providing them as illustrations regarding what could be done. However, I do believe that starting with a task based analysis is an absolute requirement:

 

Consider your end users and try to define the set of tasks that they commonly perform:

 

1. End users need an easy method to find tables where they can watch

2. End users need an easy way to find partners

3. End users need an easy way to find their friends

4. End users need to understand what tournaments are being offered

 

Once you understand the task, make it as easy as possible for folks to accomplish them... From my perspective, the main lobby is more of a "default" than a solution to any real problem.

[DrTodd13]

1) A person logs in

2) A person logs out

3) A person changes his profile

4) A person goes into or out of brb mode

5) A table is created

6) Table options are set/changed

7) A person joins or leaves a seat

8) A table is destroyed

9) A lobby chat message is sent out

10) A tournament is created

11) A tournemant's is edited or its status changes

12) No doubt several other things I have not thought of

 

I don't think it would make much of a difference to me if you changed that to:

1) A friend logs in

2) A friend logs out

3) A friend/ someone playing/(kibbing) at my table changes his profile

4) A friend/ someone playing/(kibbing) at my table changes brb mode

5) See that a table is created only if i activate a table view

6) see 5

7) only if it's my table or i view the table list

8) see 5

9) Do you mean chat to Lobby (all), i don't need that i have lobby chat turned off

But it might make sence to create a team match chat room (smaller group)

10) Only need that information when i activate a tourney list view

11) see 10 or if i am registered or put myself on the partnership desk

12) Lets deal with them when they come up.

 

Worst thing that could happen is that it takes a few (milli)seconds, if i enter the table/tourney list, but I'm doing nothing else then.

 

Does your ISP support broadcasts on IP level? You create a "broadcast IP-number" at your ISP's router, that represents e.g. all IP-numbers of kibs at a vugraph match. If you send the data to this "broadcast IP-number" at your ISP's he will distribute the message to all clients in the IP-list defined before. Save bandwidth between you and your isp, but your isp will charge the full outgoing traffic of cause.

Several years ago, I remember noting in my work that no US ISPs had IP multicast turned on. To my knowledge, that is still the case. Even if one ISP did it, you'd need every ISP to do it to help the vugraph issue. The only moderately useful "multicast" services are all overlay based means they are implemented on top of the network and not within it. MBone is just such an example. It would be pretty cool if vugraph video was broadcast on the MBone. I'd go through the hassle of installing the stuff if I could get it. Anyway, I think there are some services that for a fee will provide the multicast overlay infrastructure but since we have clients all around the world anyway we essentially have such an infrastructure for free. I sent Uday a link to a software library that allowed you to implemented your own multicast overlay network. You could use clients to really decrease the server load for really popular points of interest like vugraphs.

[fred]

Uday and I both agree with Hrothgar (and others) that the massive lobby list is not particularly useful. I think that people *should* have the ability to list all of the people who are online and filter that list in various ways, but I think that most people would prefer to see just a small subset of this list most of the time.

 

However:

 

1) We already have the View button and this allows people to customize the lobby list as they see fit. Perhaps the default should not be "show everyone", but new users (who have no friends and don't know what stars and yellows are) might find it strange to log in and see a very small list. Presumably those of you who have posted about "only wanting to see friends and stars" already use the View button for this purpose.

 

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

 

- You receive a chat message and what to know who it is from

- You go to the partnership desk and want to know the profiles of the people whose names are included

- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

 

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

 

So when you say:

 

"I'd guess that you can realize enormous load savings with minimal impact on end users simply by redesigning the main lobby."

 

I am sorry, my friend, but your guess is wrong B)

 

Whatever we choose to do in terms of scaling, what we now call the "lobby' (ie the first screen you see when you log in to BBO) will likely be different in the future.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[fred]

Sorry I have to stop working for the day soon and I don't have time to properly address the good points made by Dr. Todd, hotshot, and others.

 

For now all I will say is that I still think that all of your concerns and desires will be addressed by the way I see the mini-BBO plan working. Perhaps I have not done a good job of describing the user experience that I envision. I will try again tomorrow.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[Patapon]

I have read most of this thread but i am still not sure to understand very well how would work the 'mini BBO'.

 

Let's take examples:

 

Let's say I log in to a mini BBO, the one with the main bridge club.

 

- Could I see all my friends online even if they are logged in to another mini-BBO and could I chat with them?

- Could I register for a tournament and invite any players online to play with me, even if they are logged into another BBO? And then should I change my log into another mini-BBO to play the tournament?

- Could I know if a vugraph is running on BBO2 when I am logging in to BBO1 and should I change my log to watch the vugraph?

 

If I just have to log off and log on in to another BBO to watch a vugraph or play a tournament I have just registered for, I don't think it would be a real discomfort since it doesn't take more than two seconds to log off and on again.

But if I can't see, chat or invite my friends through the different BBO then I think it can't be a good idea. Nobody wishes to see BBO divided.

 

Benedicte

[david_c]

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

 

- You receive a chat message and what to know who it is from

- You go to the partnership desk and want to know the profiles of the people whose names are included

- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

 

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

I'm convinced that in general the "as needed" approach is preferable. It seems fairly clear that for the three examples Fred gives of why profile information may be needed, "as needed" is the better way of providing the information. This is simply because the amount of infomation involved is small (being a mathematician I would call it "bounded"), so the wait would not be very long (tiny compared to the expense in keeping all users updated).

 

An "as needed" approach would be useful even when there is an obvious need to be "in synch", as for example when you're looking at a list of tables. The point is that you only need to be "in synch" with one part of BBO at a time. There would surely be a huge difference in the load on the system if each user was only ever in synch with at most one of:

- full online list

- tables in main bridge club

- tables elsewhere

- tournaments

etc.

 

But there's one thing which people want to be in synch with all the time: that is, which of their friends (and other interesting people) are online. In order to provide this information on an "as needed" basis, the server would need to know the friends of everyone who was currently online. And whenever someone logged in or out, the server would have to search to find out who had this person as a friend. I'd have thought that this would be much more of a load on the server than the current method. So, the fact that we're only interested in a small subset of the online list is of no help at all; we're doomed to be in synch with the entire online list whatever happens ... or have I analysed this wrong?

[TimG]

I personally don't think "constantly in synch" is necessary, but it is certainly desirable in some areas. For example, if you are looking at a list of table in the hope of finding a place to play and if the list doesn't update itself automatically, you will frequently try to sit in an empty seat that has since been filled. Furthermore, having to click a "refresh" button constantly is a big pain. People with slow connections would also suffer every time they went to into the Main Bridge Club (or clicked the "Tables" button) because they would have to wait for the table list to download. The bigger BBO gets the bigger these problems get.

Does all information have to be treated the same? Yes, if I'm looking for a table with an opening, it makes sense to have the table information constantly updated for the tables with openings. If I'm looking for a table at which to kibitz, a non-refreshed list will be sufficient 99% of the time, and I'm sure I can live with the occasional attempted trip to a table that has just closed.

 

In the lobby, we can use the "view" option to limit which players are listed (something I was not aware of until reading this thread), but as I understand it, even if I set my view to show friends only, the complete list of players is constantly updated in the background. That is, changing the view preferences does not change the bandwidth used.

 

Once I see a listing of available vugrah shows, I can mouseover the tables and see who is playing. Once I join a vugraph table, I can mouseover the table and see who is kibitzing. Somebody who signs on to find a pickup game has no need for any of this vugraph information. (And, someone who signs on to watch a vugraph has no need to have the main bridge club table info.) Would it be possible to turn on the constant updating for vugraph tables inly when the member has entered the vugraph theatre (or even the explore bridge menu screen)?

 

If it is possible, the same could be done for other areas: only turn the background updating on for the area where the player is, make it a request for other areas.

 

Tim

[fred]

2) Even if the client doesn't display the complete lobby list, it still *needs* the information (ie the IDs and profiles of those who are logged in) for various things. For example:

 

- You receive a chat message and what to know who it is from

- You go to the partnership desk and want to know the profiles of the people whose names are included

- You go to the Main Bridge Club list and want to know who the people are who are playing at various tables

 

Yes, we could make it so that profile information was sent to the client on a "as needed" basis, but that would not only require a lot of new coding a lot of rewriting of old code, but it would also mean having to do a lot of waiting for profiles.

I'm convinced that in general the "as needed" approach is preferable. It seems fairly clear that for the three examples Fred gives of why profile information may be needed, "as needed" is the better way of providing the information. This is simply because the amount of infomation involved is small (being a mathematician I would call it "bounded"), so the wait would not be very long (tiny compared to the expense in keeping all users updated).

I think you are wrong.

 

First of all, the amount of data that you have to wait for is not the only relevant factor. It takes time for your request for that data to get to our server, for our server to process that request, and for the data to be returned to your PC. Also, if the basic system design is changed so that the server starts to receive a *lot* of these kinds of requests, there is danger that it will become bogged down trying to deal with them.

 

Second, you use words like "preferable" and "better" inappropriately in my opinion. "Better" from what point of view?

 

Clearly from the user's point of view better means:

 

- Client never has to wait for anything

- Client interface is designed so that it is always easy for user to see and do whatever he wants

 

Whereas from the server's point of view, "better" means:

 

- Server does the minimal amount of work per user so that it can handle as many simultaneous users as it will ever need to

 

What is "best" for the user directly contradicts what is "best" for the server.

 

Our mission is to change the basic client/server and/or client interface design so that this contradiction can be managed for large numbers of users while at the same time minimizing the negative impact that these design changes will have on the user experience.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[fred]

Answers to questions from Patapon:

 

- Could I see all my friends online even if they are logged in to another mini-BBO and could I chat with them?

 

Yes.

 

- Could I register for a tournament and invite any players online to play with me, even if they are logged into another BBO? And then should I change my log into another mini-BBO to play the tournament?

 

Yes and yes (though you wouldn't have to do anything when the tournament started - the software would automatically connect you to the appropriate mini-BBO)

 

- Could I know if a vugraph is running on BBO2 when I am logging in to BBO1 and should I change my log to watch the vugraph?

 

Yes. The default would be for all vugraph tables be "shared" among all mini-BBO, but we might want to give vugraph operators the ability to create "private" vugraph shows that would be available on only 1 mini-BBO.

 

Same goes for things like tournaments and private/public clubs. The default would be that these things would be shared by all mini-BBOs, but we would likely build in the ability to restrict access to such things to people logged into a particular mini-BBO (or particular mini-BBOs).

 

The main differences between what we have now and what we would have under the mini-BBO plan (at least as I see it) would be this:

 

1) Each mini-BBO would have its own Main Bridge Club and each of these Main Bridge Clubs would have their own unique lists of tables.

 

2) The lobby list of a given mini-BBO would contain only people logged in to that mini-BBO.

 

3) We would create a new window that contained things like a list of all available mini-BBOs and a customizable list of people logged in to those BBO (perhaps the default would be friends only, but you could also use something similar to the current View button to change the contents of this list).

 

This window would be available at all times. It could be used for things like switching to a different mini-BBO, chatting with people on other mini-BBOs, etc.

 

So when you first log in you would see this window. When you then use this window to log in to a given mini-BBO, you would see something similar to what you see now when you log into the one and only BBO. After you logged in to a given mini-BBO, this new window would remain available.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[TimG]

- Client never has to wait for anything

When I sign on to BBO, I get a couple of messages:

 

"Logging In. Please Wait."

 

"Loading Player List. Please Wait."

 

So, you'll never achieve perfection in this area. There also must be some delay with the communication of data under the current background updating environment. It's probably cut up into very short delays so that we hardly notice, if we notice at all. I wonder: would there be fewer apparent delays in bids or cards played if background updating were not constant?

 

Not that this is meant as a criticism. I expect to wait for some things. I expect to wait while a connection is established and some system state is communicated to my computer. I think you would also find that most people would accept (even expect) to have some minimal wait when some things (like a lobby listing) are requested.

 

You should be aware that while I may seem to have a strong opinion here, any change to mini-BBOs is unlikely to alter my usage habits. So, perhaps, my opinion is not one you need to hear. (And, just maybe, I'll manage to keep quiet on the matter from here on out! :D )

 

Tim

[hotShot]

What about this:

 

I guess each user has an ID ( think 4Byte integer should do) than sending a message to all user takes

active user * 4 Bytes as an initial Message. Adding 2 extra Bytes for the table number (could make problems if BBO reaches 32000 active tables) (table 0 is lobby) and one Byte bitcoded N/S/E/W /Kib /Yellow/tourney/logoff / changed profile etc. will lead to 7 Bytes per active user at login as an absolute minimum.

 

When installing BBO (not at update) the usernames and id are mirrored in a local database. Name and id cannot be changed so these data never expire. It could also contain the friend/enemy status. The profile of friends should be mirrored locally too.

 

If i want to see someone's profile the request is send to a different server e.g.

profiles.bridgebase.com this server is just handling the profile. This could be done with a direct connection to a database server. Parsing the SQL request output is done by the client. Keeping the answers fast could be done e.g. with a MYSQL cluster (but i guess BBO must grow a lot before that is necessary). People could choose how much space they would be willing to reserve for cached profiles, if there is space left those profiles can be mirrored locally too, if a login message indicates a profile change it is marked invalid in the local database, and called again from the server.

I guess profiles of 100000 user take about 50MB,Not transmitting all the profiles all the time would help to save bandwidth and allow faster logons. (Guess you do a lot of this already.)

 

Login and logout, seating information change of status will lead to 7 byte messages. Since these messages are send to all users this can be done by some sort of client based distribution. If you send this to 2 player at the table asking each to redistribute the message to the 2 others, the others might get the message twice, but the will sure get it. A similar idea can be done with table chat. I know you don't like to rely on the clients, but sending update information only to half of users using them to proxy the data to 2 others will reduce the bandwidth you need. If each message has a message id, a client can see that he missed something and can contact a server lostmessage.bridgebase.com asking for the message with the missing id. Or take a look at all those bittorrent distribution systems. They work! Since you can really save bandwidth this way you should think about it.

[uday]

maybe, I'll manage to keep quiet on the matter from here on out

 

No, don't keep quiet just because one of us disagrees with you!

[fred]

We already do similar things to almost everything hotshot describes in his post.

 

Implementing these sorts of things has bought as a lot of time and greatly increased BBO's maximum capacity over the years, but they are still what I would call "bandaid solutions". There are probably still a few clever undiscovered bandaids out there, but eventually we will run into a brick wall as far as the existing architecture is concerned.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[Rebound]

Answers to questions from Patapon:

<snip>

This reply is sufficient to pretty much address every concern I may have had regarding the changes. The way you describe it, Fred, it sounds perfectly fine to me :-)

[Rain]

My dream BBO, hopefully it'll be incorporated in the next 3 years. Similarities to WOW and other MMP games are intended.

 

You login to BBO and are asked to select an avatar. If fred decides to provide a premium BBO service, an additional feature would be more avatars for premiums, and ability to customise avatar. (hairstyle, facial features, clothes or no clothes)

 

Next you choose a realm to play in. Each of these have specialisations, and are the mini-BBOs mentioned. Instead of naming them "China BBO" or "Italian BBO" they get cool names like "Forbidden City (with chinese translation) and "Leaning Tower (with Italian translation)". Each realm has its own themed colour scheme and background pictures.

 

When you enter, you appear to be walking in the 3D realm. If people are standing, they are in the lobby/idle. If they are playing, you'll see them sitting and playing. Seats are also different depending on which realm. Eg will be if you are in Japanese land, you see people kneeling at a Japanese low table and playing cards, heh.

 

Your avatar can walk around the landscape scattered with tables, or they can just click on menu buttons on top to locate friends and join their table.

 

Once at table, you get to kibitz 1 person at a time. If you want to kibitz 2, you need to stand behind 2 people. If you want to kibitz all, you'll be magically suspended on top of table.

 

When playing, you will sit at a table, and hold cards in your hands. The camera is behind you so all cards are clearly shown.

 

----------------------

Bonus/special points:

 

You get certain interaction chat like actions that your avatar can do. (The bbo version prior to this isn't as advanced, and will only have emoticons) Eg, and this is blatant lifting, you choose "shake hands" and your character shakes hand gravely with other users. Or dance. Or laugh, which will cause your avatar to roll on floor and laugh loudly)

 

The more boards you play, the more activities you do in BBO, the more experience points you get. The more experience points you get, the more benefits and privilages you get. If you don't play for a long long time, you can also lose XP. The special feature we have will be: If anyone abuses you, you can draw your weapon and hack at that person's avatar. Around the landscape there will also be interactive features for you to interact with to distract you more from bridge. Something like a rhino or hippo or giraffe that you can ride if you are in the african part of the landscape.

 

If you want to buy BBO$, you go to the bank and your character will get a theft-proof bag with coins in it to jiggle.

 

If you play in a tourney (if pay tourney, you get to hand a sweet looking TD your silver coin) and play too slow, the TD can choose to make angry faces at you. If that fails, they can also adjust your score.

 

There are special "Quests" you can do to gain more XP. These will mostly be tutorials around this new BBO or a Guide on how to be a good TD with a quiz at the end.

 

To travel from 1 realm to another, you can actually walk to the "bridgeport" and take a "travelling scorecard" to the next realm. (There will be a cool, very short clip with "wheeeeez!" showing you sitting on travelling scorecard and going to the next realm's bridgeport". You don't get frequent flier miles, but you do get to sit in the clubhouse if you are of a high enough level.

 

 

How about it Fred? BBO 2008? Or 2048 =(

 

Rain

[david_c]

This reply is sufficient to pretty much address every concern I may have had regarding the changes. The way you describe it, Fred, it sounds perfectly fine to me :-)

Yeah, I agree :D There are a couple of things that I don't quite understand though:

 

Firstly, it seems that we will still be able to see everyone who is online. Which is great news for the user, but surely it's just as much of a burden on the server as the online list is at the moment. Now, at the moment, on average one in every n pieces of information sent is used to update the online list (I don't know what n is, about 20?). I suspect that this n is a constant, not depending significantly on the number of people online. If so, then as long as we are going to have a complete online list, we'll never be able to improve the situation by more than a factor of n, no matter how many mini-BBOs there are. And that means, if the membership of BBO increases by a factor of sqrt(n), which we hope will happen eventually, the servers will be just as busy as they are at the moment ...

 

Secondly, if there are lots of near-identical mini-BBOs, how would you prevent the situation where everyone joins just one of them? The bad way of doing it would be to put a limit on the number of people in each one - that's bad for very obvious reasons, but it's the way this is done on many other sites. Is there a good way?

[Walddk]

I have read enough to determine that Fred and Uday are on the right track. I am no technician, so as a simple layman I would like to state:

 

Continue as you see fit. I am sure that whatever you do, it will be in the best interest of BBO and its members. There will always be some who don't agree with your decisions, but that applies to anything you will or will not change.

 

Forget about pleasing everybody, perfectionism does not exist. Do what the majority would think is a good idea for as many as possible. I think that this thread has clearly indicated what that majority wants ......

 

... and you, Fred and Uday, have clearly told us what will be involved when the changes are implemented. I will not lose any sleep over it. The new look BBO, whenever that may come, will definitely be a place I would want to visit as often as I do now.

 

Who said 24 hours a day? :D

 

Roland

[scoob]

i should have read this thread before i posted in the other one :rolleyes:

[DrTodd13]

Fred is totally aware of this issue I'm sure but for those who aren't and are suggesting it, one could really mess things up if you adopted the approach of "we'll only keep one area in synch at a time" where area is main lobby, tourneys, tables, vugraphs, etc. If I pop into the tourney area and have to get a full tourney list, that will take some time. As it is now, it takes essentially 0 time because we are constantly being updated. Then I decide to pop back to the main lobby. Now, assuming that I stopped receiving lobby updates when I was looking at tables or tournaments then now I have to get the whole lobby list again. If I pop back and forth a lot and do the obvious (but stupid) thing is registering for updates when I join an area and desregistering when I leave then you can really increase server load this way.

 

Personally, the main lobby being always in synch regardless of where you are in BBO is not a bad idea. You just have to define main lobby as your friends rather than everyone and you have to move the filtering function from the client to the server just like Yahoo does it. You could still get a list of everyone but that would be on an on-demand basis.

[rigour6]

Ok, a few cents again.

 

1) These (i.e growth) problems are good problems to have.

 

2) It is difficult for people to see the need for this now because the problem hasn't yet run us over. We had a taste of it when the rush to the Vugraph slowed things, but so far the system works so well, people don't see the issue. If the system maxes out, performance doesn't just decline - it plummets.

 

3) Right now, the lobby isn't much use because it's too full. So why have it? Dump that off somewhere and only provide that information on user requests. In other words, use the space for things that are useful.

 

4) In a similar vein, how useful is a Main Room with hundreds and hundreds of tables? How many are you going to play at? When the system fills, players will have frustrations because they'll go to sit down only to find the seat taken, on the next one same thing. Again, spin that off. Or spin off tourneys.

In other words I would much rather see a system that split players by what they were doing than where they lived - even though I know one of the main gains in response comes when you can get people choosing a localized entry point.

I say this because even though groupings by language are natural, to me one of the great advantages of the bbo community is its cosmopolitanism. My guess is the most natural seam would be North America / Everyone else. Without getting into a whole thing here, imho the world needs less things in which it's America / Everyone Else.

 

5) Now my one perhaps decent suggestion (it's your reward for reading to end): has BBO done any study into what users do? In other words, what are the migratory patterns of a "typical" BBO user. My guess is there won't be a single profile, but there will be identifiable groups. There'll be the users that ALWAYS go to the Main Club and stay there. There'll be the users that usually stay in the Tournaments.

 

Find out what the migratory pattern of fish are and you know where to have your fishing seasons and when. Find out the migratory pattern of BBOs, and you'll know where to put your seam. What if it turns out that 48.6% of all users log ONLY into the Main Room and stay only there? Now you've got a big increase in functionality if you put a seam there - sure people will move back and forth but you add a step there and they cross from one server to another.

 

Follow those fish and see where they go.

 

 

 

 

 

 

btw, 48.6% of all statistics are just made up on the spot.

[shoeless]

Hey Rigour6 as Stephen Leacock (humorist and professor of economics at McGill in Montreal) said - "There are lies, damn lies and statistics" Mostly I just want to add my add my support to Roland's comment and expand on it slightly - Leadership is about doing the right thing and since BBO in all it's aspects is coursing through your veins - I can't image you will be much off the mark whatever you do. Your report card so far looks pretty much like all A's. Go for it! Of the 10 people who quit because they don't like the change - 48.6% of them were going to quit anyway. My biggest concern on BBO to this point is: "What nick is De Falco using today?" Put a bell on him and I'll be happy.

[hrothgar]

Hey Rigour6 as Stephen Leacock (humorist and professor of economics at McGill in Montreal) said - "There are lies, damn lies and statistics"

I believe that the quote originated with Samuel Langhorne Clemens...

[rigour6]

Benjamin Disraeli

[hrothgar]

Benjamin Disraeli

This is the problem with growing up in the US...

We tend to ignore a lot that happened out side out continent

 

Up until a minute ago, I thought that Clemens had originated that quote

[shoeless]

I can now go to bed tonight secure in the knowledge that I can misdefend, misbid, misdeclare and misquote. Statistical analysis of the probability of this occuring in one 24 hour period to follow - likely 48.6% of the time.