<p>Jon, James,</p>
<p>Thanks for your thoughts and advice. I know Steve is familiar with GemStone but I'm not sure whether he is aware of GLASS.<br>
No doubt he'll have further queries when he sees your comments.</p>
<p>Cheers,</p>
<p>Dirk</p>
<div class="gmail_quote">On 23/02/2012 10:07 AM, "James Foster" <<a href="mailto:Smalltalk@jgfoster.net">Smalltalk@jgfoster.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Dirk,<br>
<br>
It is certainly true that having a relatively clean separation between the layers (infrastructure, domain, application, and UI) is a good design principle. And Steve is right that building a complex network of objects that cannot fit in memory is not very scalable.<br>
<br>
On the other hand, if you have a tool that allows you to act like you have a huge transactional object space that is shared by hundreds of concurrent sessions, where your "stored procedures" are written in Smalltalk, and Seaside support is built-in, then your prototype might not be so unrealistic. Have you heard of GemStone/S? Check out <a href="http://seaside.gemstone.com/" target="_blank">http://seaside.gemstone.com/</a>, and the various links from there, including my blog at <a href="http://programminggems.wordpress.com/" target="_blank">http://programminggems.wordpress.com/</a> and Dale's blog at <a href="http://gemstonesoup.wordpress.com/" target="_blank">http://gemstonesoup.wordpress.com/</a>.<br>
<br>
Feel free to ask more detailed questions...<br>
<br>
James<br>
<br>
<br>
On Feb 22, 2012, at 3:33 PM, dirk newbold wrote:<br>
<br>
> 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>
><br>
<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>