Well after skimming the message below, one word comes to mind "Glass" <a href="http://seaside.gemstone.com/">http://seaside.gemstone.com/</a><br><br>Read over that they have to offer with respects to scaling. The data sharing between sessions/threads/whatever you will get for free due to the way Gemstone is setup. Porting should be quite easy.<br>
<br><div class="gmail_quote">On Wed, Feb 22, 2012 at 3:33 PM, dirk newbold <span dir="ltr"><<a href="mailto:dirkdirk@gmail.com">dirkdirk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I’m a relative newbie (4 years) to programming and seaside, who<br>
partnered up with some “old hands” (smalltalk/seaside is my first and<br>
only language).<br>
<br>
Initially we developed an Ecommerce (Istazaar) fashion platform for<br>
designers to maintain their collections. We stagnated last year due<br>
to the time restraints on the “old hands” and I then began developing<br>
a web based Enterprise Software (Vivport) platform for<br>
document-management/knowledge-management/emails/tasks.<br>
<br>
We now have two ventures at relatively equal stages of development.<br>
I believe the Enterprise Software (Vivport) platform is the more<br>
innovative however, now that Steve (one of the “old hands”) has some<br>
time again he has been able to review its development (which<br>
unfortunately I built unsupervised) and has major concerns in relation<br>
to deploying this venture.<br>
<br>
Instead of building the database; then building middleware, then UI;<br>
I’ve basically just built a UI, Steve’s concerns with the outcomes of<br>
this development process are outlined in his email to me below.<br>
<br>
We were wondering if the smalltalk/seaside community has any views on<br>
Steve’s concerns below that may influence our decision on which<br>
venture to proceed with.<br>
The platform has been developed to freely change between the user’s<br>
personal account and their company(ies) account. The personal<br>
accounts are free so we would be attempting to server many users.<br>
<br>
Any advice in relation to users/image, persistence, database, general<br>
deployment etc for this type of venture (essentially a beefed up<br>
gmail/cloud environment) would be greatly appreciated.<br>
<br>
Thanks for your time.<br>
<br>
Cheers,<br>
<br>
Dirk<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Steven Berryman <<a href="mailto:Steven@berrymanelectrical.co.uk">Steven@berrymanelectrical.co.uk</a>><br>
Date: Sat, Feb 18, 2012 at 6:07 AM<br>
Subject: RE: Vivport V Istazaar<br>
To: dirk newbold <<a href="mailto:dirkdirk@gmail.com">dirkdirk@gmail.com</a>><br>
<br>
Dirk,<br>
<br>
As mentioned I’m concerned with the approach you have taken with<br>
Vivport and in one way this technology can lead you into a false sense<br>
of how easy things are (trust me you couldn’t have done it in .NET or<br>
java without infrastructure). The difference with the ecommerce site<br>
is that there is little shared data and I knew that the only real<br>
issue was storing users but that would be a simple mapping issue to a<br>
table. Even the registered objects were designed to make storing in<br>
the database easier so objects didn’t directly hold onto a registered<br>
object. What you have built is a very complicated network of objects<br>
for the benefit of the UI which for a prototype is great but would<br>
never work in the real world. The type of project you are building<br>
with Vivport is infrastructure and in one way the last thing you<br>
should have done is the UI. One system I worked on had 3-4 months of<br>
designing the infrastructure before a line of code was written.<br>
<br>
<br>
<br>
The problem you have is that you have assumed that all objects would<br>
be in memory and are accessible via threads and this just isn’t<br>
possible. If I look at my local Microsoft exchange server it’s<br>
currently 50GB for 5 users and the machine only has 4GB of ram so not<br>
only do you need to deal with large amounts of data but you have not<br>
addressed any multi-threading issues. For example Smalltalk provides<br>
structures such as SharedQueue to deal with any shared data in the<br>
memory and I’m guessing you didn’t use these? When everything is in<br>
memory the world is very easy but for a system like yours you would<br>
need to start with the database and design the schema. Most searches<br>
would be done directly in sql (assuming you are using a relational<br>
database) so that way you reduce the amount of data going to the<br>
client. So when you open up Microsoft Outlook it will run a query on<br>
the database to get your inbox and the email headers so you don’t pull<br>
large amounts of data across the network. As you start to click on<br>
emails it will pull the data over as required.<br>
<br>
So here is an example to show multi-threading issues (I have not used<br>
your code but I’m sure you get the point)<br>
<br>
Lets’ assume you have a folder with 10 items<br>
<br>
Dirk - actions Danny - actions<br>
folder items do: [ :item<br>
“goes through this loop twice”<br>
delete the last<br>
item in the folder<br>
“code falls over because the last element<br>
in the collection does not exist.” ]<br>
<br>
I’m sure you could try something like the above but you would need to<br>
put in a break point in the Dirk loop so you could then go in and to<br>
the removal from a different session. Now imagine the same thing with<br>
5,000 users logged into your server all running threads across your<br>
code. Your code would have to be thread safe and this is not a simple<br>
task especially trying to do it on code not designed that way from the<br>
beginning. You could end up locking up all the other sessions if you<br>
don’t carefully design and keep your critical sections to a minimum.<br>
<br>
If you are using collections that are hashed they will fail in very<br>
strange ways if you have other threads removing or adding items as you<br>
are iterating through the collection. Basically in the ecommerce site<br>
we could sort of ignore the shared data issue as we shared very little<br>
data between sessions.<br>
<br>
Also you have added features that would be very expensive when using<br>
databases. For example the running man relies on the status of some<br>
piece of data and of course when everything is in the same memory<br>
space this is easy. In a database you would have to cross a<br>
transaction boundary and even the fastest database servers we have<br>
(costing 200k per server) you would be lucky for a single transaction<br>
to take between 1-10 milliseconds (costly when you scale up users and<br>
make too many database calls). This is why Microsoft exchange works<br>
the way it does as you can imagine how slow it would be if 5000 people<br>
logged into the server at the same time. So for most document<br>
management systems they would have a large database at the back end<br>
and all the searches would be done as stored procedures that could be<br>
based on some proprietary algorithm and none of this would be done in<br>
the language itself such as Smalltalk. Until you have a database<br>
schema designed you can’t even think about the UI.<br>
<br>
If you want to prove to yourself then try and create 100,000 users all<br>
with about 10MB of data and test to see if it works. See if you can<br>
log in a few sessions and send emails around.<br>
<br>
With the ecommerce site I could imagine how to add a database at the<br>
backend because it would be very simple. I would have no idea how you<br>
get this into a database even if you used an object database you would<br>
still need a defined object model. It’s also the reason why I liked<br>
the ecommerce site as it would be simple from the database end as it<br>
would only contain users, basic static data and designer’s data. Also<br>
I can see how we could have multiple servers to handler more traffic<br>
with the ecommerce site but would have no idea how we could do the<br>
same with your design.<br>
<br>
Hope this makes sense. Let’s catch up next week.<br>
<br>
Steve<br>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</blockquote></div><br>