<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hey Dirk,</div><div><br></div><div>I think you did the right thing in your app and what Jon and James told you sounds right.</div><div><br></div><div>Here you have my point of view explaining a little more on why I think they're right (in a more general post):</div><div><a href="http://sebastianconcept.com/brandIt/on-persistence-architecture-and-scaling">On Persistence, Architecture and Scaling</a> [1]</div><div><br></div><div>hug</div><div><br></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><a href="http://about.me/sebastianconcept">sebastian</a></div><div><br></div><div>o/</div><div><br></div><div>[1] <font class="Apple-style-span" color="#144fae"><u><a href="http://sebastianconcept.com/brandIt/on-persistence-architecture-and-scaling">http://sebastianconcept.com/brandIt/on-persistence-architecture-and-scaling</a></u></font></div><div><br></div><div><br></div></div><div><div>On Feb 22, 2012, at 9:33 PM, dirk newbold wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br></div></blockquote></div><br><div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div></div>
</div>
<br></body></html>