<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial" 
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document 
face=Arial color=#000000 size=2>
<DIV>
<DIV>
<DIV>In a message dated 6/11/2005 12:03:50 P.M. Pacific Daylight Time, 
sword-devel-request@crosswire.org writes:</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT 
  style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 
  size=2>&gt;Robin,<BR>&gt;&nbsp; &nbsp; There a number of issues involved with 
  considering moving to <BR>&gt;try/throw/catch error handling.&nbsp; The first 
  one that comes to mind is <BR>&gt;language binding.&nbsp; Second is 
  cross-platform portability with OSs like <BR>&gt;PocketPC, which, if I 
  remember correctly don't have compilers that <BR>&gt;support exceptions or 
  RTTI.&nbsp; I'm not in a mental state to debate the <BR>&gt;merits of either 
  system for a few months, but we have a long running <BR>&gt;list of 
  improvements to the engine.&nbsp; If it is something you have a 
  <BR>&gt;practicle reason for desiring, please open a new feature request and 
  <BR>&gt;include justification and we'll not forget to address the issue 
  <BR>&gt;(actually this goes out to anyone who wishes to switch error handling 
  <BR>&gt;models).<BR>&gt;<BR>&gt;&nbsp; &nbsp; -Troy.<BR>&gt;<BR>&gt;PS.&nbsp; 
  I think we've done a pretty solid job to keep memory usage down to <BR>&gt;a 
  minimum.&nbsp; I'm not sure that any of our apps are running out of memory 
  <BR>&gt;doing anything these days.&nbsp; We run on some small platforms, like 
  PDAs <BR>&gt;with as little as a total of 16MB of RAM.&nbsp; The optimizations 
  to make us <BR>&gt;work in these environments have left us with a fairly lean 
  memory <BR>&gt;footprint, even on larger systems.&nbsp; Most of our objects 
  which allocate <BR>&gt;and cache resources implement an SWCacher interface 
  with <BR>&gt;resourceConsumption and lastAccess reporting, and a flush method 
  to ask <BR>&gt;them to clean up.&nbsp; We where planning on writing a CacheMgr 
  which all <BR>&gt;these SWCacher object could be handed to, that would monitor 
  these <BR>&gt;objects and keep total resourceConsumption within a reasonable 
  <BR>&gt;tolerance, but haven't done so yet.&nbsp; That was a long 
  PS.<BR></FONT></BLOCKQUOTE></DIV>
<DIV>It's just a wish list item for me at this point.&nbsp; I'll let someone 
with more knowledge of all</DIV>
<DIV>the issues/consequences write up the "improvement/new feature docs.&nbsp; 
Go have a vacation:) or whatever. (Like DM or Barry)</DIV>
<DIV>&nbsp;</DIV>
<DIV>In His Grace,</DIV>
<DIV>Robin</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT lang=0 face=Arial size=2 FAMILY="SANSSERIF" PTSIZE="10">Phone: 
650-948-8037 <BR>Fax: 650-948-9337 <BR>Cell: 650-518-0025<BR>E-mail: 
</FONT><FONT lang=0 face=Arial color=#ff0000 size=2 FAMILY="SANSSERIF" 
PTSIZE="10">RLRandallX@aol.com</FONT></DIV></FONT></BODY></HTML>