> On Jan 7, 2016, at 12:02 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Thu, Jan 7, 2016 at 1:45 PM, Craig L Russell
> <craig.russ...@oracle.com> wrote:
>> Hi Sam,
>>
>>> On Jan 7, 2016, at 7:00 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> I'm going to ponder this input for a while. You don't like context menus,
>>> would like to have a confirmation dialog telling you what is going to
>>> happen before you commit, and would like to have progress updates as the
>>> changes occur (and if that is not workable, at a minimum tell you what
>>> happened at the end).
>>
>> The new tool currently doesn't have a commit button. Perhaps I misunderstood
>> your intent with the confirmation dialog, which currently says "stub for
>> ICLA, filename: robert-pozarickij-xxx" and then has a single "OK" button.
>
> You didn't misunderstand. My previous intent was that file would do a
> commit. I now have more feedback from you that that is not what you
> want.
>
>> If the intent is to use a real dialog box to detail what happened (svn
>> status of the documents directory, svn diff of the officers directory),
>> propose a commit message, include the cc: list for the email, and then
>> prompt for (Commit) or (Cancel):
>>
>> Yay.
>
> Essentially, yes. My current thinking is to take back over the right
> pane once you push file, and have all of the elements you describe
> above. Once you push commit, the status of items will update as they
> complete, much like the current workbench does.
Ok. The right pane isn't really useful to display the document once the
document is in the "pending commit" state.
>
>>> All possible.
>>>
>>> The primary way in which this tool is different than the current secretary
>>> workbench is that the workbench is completely svn working directory
>>> centric. Everything happens in the working copy. You fetch it from the
>>> server. It contains everything, including spam. Every operation(burst,
>>> rotate, staple) happens there. Sometimes it gets out of sync, but it
>>> mostly works. When you think you are ready, you do a commit.
>>>
>>> In the current tool, nothing happens in svn until the very end. For
>>> example, spam never gets added to the repository, so there is no need to
>>> mark it as a dup, spam, incomplete or whatever, and then perform a commit
>>> completely with a confirmation dialog and progress updates.
>>
>>> Simply delete it and move on.
>>
>> If it is spam, I agree. I just need a delete button. Maybe a spam column in
>> the main window. I would use the spam button for messages such as "EVENTS
>> MANAGEMENT PROTOCOL & ETIQUETTE SEMINAR FOR UN AGENCIES, GOVERNMENT &
>> INTERNATIONAL ORGANISATIONS".
>
> At the moment, there is no button, but "command-delete" works from
> both the main window and when viewing an individual message. In both
> cases, it deleted the entire message (subject to undo). My feeling is
> that that is cleaner than cluttering the window with a spam button per
> line or requiring you to select a row and then move your cursor to
> where the button may be.
As long as it's obvious and the mail can be deleted from the main window or
from the message window.
>
>>> At most, send an email.
>>
>> From the main window, this wouldn't work. There is context for emails. If a
>> signature is missing, I want the email to be copied to pmc and ppmc.
>>
>>> If you change your mind, undelete it and process it.
>>
>> If it's deleted, where would I see it?
>>>
>>> Same thing with respect to rotating, bursting, and stapling. Nothing goes
>>> into SVN until you say so. In fact, since you are adding new documents,
>>> I'm hoping to use svn import instead of svn update; svn add; svn commit:
>>
>> Good. From the message window, when I click a file, the menu should include
>> all of the icla, ccla, grant, mem items but also burst, rotate, etc. These
>> are currently under "other" but it's easier if it's just radio buttons on a
>> second line. No confusion.
>
> Probably will be real buttons (radio buttons select which form is
> shown below), but at some point, I'll leave the tweaks up to you. If
> you want to begin to play, try this locally:
>
> --- a/www/secmail/views/parts.js.rb
> +++ b/www/secmail/views/parts.js.rb
> @@ -66,6 +66,8 @@ class Parts < React
>
> _CheckSignature selected: @selected, attachments: @attachments
>
> + _button 'burst', onClick: self.burst
> +
> # filing options
> _table.doctype do
> _tr do
> @@ -187,7 +189,7 @@ class Parts < React
> # burst a PDF into individual pages
> def burst(event)
> data = {
> - selected: @menu,
> + selected: @menu || @selected,
> message: window.parent.location.pathname
> }
>
>
>> Once a file has been modified, I can return to the main window (see else
>> discussion) which should bring up a dialog "Are you sure you want to revert
>> all changes?" and then all the local (on the file screen) changes would be
>> reverted.
>
> No need to revert the changes upon return to the main window. Things
> that are committed are already committed. Other changes (like burst,
> rotate, etc) will still be there when you come back. These changes
> are stored in the yml files in the officers-secretary directory on the
> machine where the secmail application is run.
What I'm concerned about is making a dog's breakfast of an email and not being
able to revert the changes.
If I spot a typo before commit, I'd like to revert everything done to the
message and its files.
>
>> We do need to think more about the burst work flow. Once burst, documents
>> need to be combined (drag/drop) into new documents, and the new documents
>> need to be filed. There are often multiple documents that have the same pmc
>> and ppmc so these fields should remain populated for multiple documents.
>
> Those fields should remain populated as long as you are processing the
> same document type and haven't left the window. Should you need more
> persistence, we can explore that later.
I've had cases of multiple iclas plus a grant or ccla in the same email
message. IIRC sometimes there is one massive pdf file that needs to be burst
and sometimes individual multi-page icla and grant pdf files.
>
>>> http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.import.html
>>> <http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.import.html>
>>>
>>> Updating iclas.txt will continue to be done as before, but that directory
>>> is orders of magnitude smaller.
>>>
>>> Meanwhile, I'm going to merge this tool into the master branch, and when I
>>> redo the commit process to add a confirmation dialog progress indicator,
>>> I'll be adding the actual commit and email logic, so any documents that are
>>> processed by one tool will need to be deleted from the other until the
>>> cut-over.
>>
>> So where are these documents? I guess when I'm running secmail on my
>> machine, "rake fetch" puts the mails locally. When running secmail on
>> whimsy, where do they go? It doesn't make sense to put it into production
>> until we actually start using secmail on whimsy. Which won't be until we
>> have all (most) of the current secretary assistant functionality implemented.
>
> rake fetch will be run (via a cron job) on whimsy. In order to debug
> secmail, I will likely file a few ICLAs. When I do so, I will remove
> the corresponding document from documents/received.
That's fine. I guess what I'm really asking is how fetch knows which messages
to fetch and which messages have been processed already and how to recover a
message that was accidentally deleted.
>
> If things go as planned, my merging the secmail branch onto master
> should cause the code to be deployed and the gem dependencies
> downloaded. Adding authentication and starting the web application
> should only be one line each to the puppet configuration. What's left
> would be setting up svn checkouts (documents, foundation, etc),
> fetching the mail, and hooking both up to cron jobs.
>
> At that point, should you want to add a button, you should be able to
> test that change locally and push it to GitHub. Once you do, it
> should be deployed for you automatically within 35 minutes.
Sounds scary. ;-)
>
> You should also be able to run this on your own machine. Getting to
> the point where you can send mail from an application (I'm not talking
> about launching an email window, but doing it from the server like the
> current workbench does) requires a bit of setup. If I recall
> correctly, you couldn't get this to work with your oracle email
> address, but were successful using gmail as the mail delivery agent.
Meanwhile, I've succeeded in installing imagemagick convert via port install.
I'm looking for some test messages to test drag/drop. No luck.
>
> But my hope is that the instance running on what is now called
> whimsy-test, but will ultimately replace whimsy, will meet your needs.
I tried to look at 2015-12-06T01:28:49Z and clicking on the file name gives an
error. [1]
We very occasionally get an icla as a single .jpg file. How would I process
this? I don't see how to convert a jpg into a pdf. The right click menu (ok, I
can live with it) gives burst, left, right, and flip. Should we add something
to convert to pdf?
Craig
[1] 2016-01-07 12:27:36 - NoMethodError - undefined method `body' for
nil:NilClass:
/Users/clr/apache/git/whimsy/www/secmail/models/attachment.rb:20:in
`body'
/Users/clr/apache/git/whimsy/www/secmail/server.rb:119:in `block in
<top (required)>'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1609:in
`call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1609:in
`block in compile!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in
`[]'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in
`block (3 levels) in route!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:993:in
`route_eval'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in
`block (2 levels) in route!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1014:in
`block in process_route'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in
`catch'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in
`process_route'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:972:in
`block in route!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in
`each'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in
`route!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1084:in
`block in dispatch!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`block in invoke'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`catch'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`invoke'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1081:in
`dispatch!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in
`block in call!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`block in invoke'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`catch'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in
`invoke'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in
`call!'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:894:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/logger.rb:15:in `call'
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/commonlogger.rb:33:in
`call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:218:in
`call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:211:in
`call'
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/head.rb:13:in `call'
/Library/Ruby/Gems/2.0.0/gems/rack-1.6.4/lib/rack/methodoverride.rb:22:in `call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:181:in
`call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:2021:in
`call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in
`block in call'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1795:in
`synchronize'
/Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in
`call'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/configuration.rb:79:in `call'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/server.rb:541:in
`handle_request'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/server.rb:388:in
`process_client'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/server.rb:270:in
`block in run'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/thread_pool.rb:106:in `call'
/Library/Ruby/Gems/2.0.0/gems/puma-2.15.3/lib/puma/thread_pool.rb:106:in `block
in spawn_thread'
>
>> Craig
>>>
>>> - Sam Ruby
>
> - Sam Ruby
>
>>> On Wed, Jan 6, 2016 at 9:14 PM, Craig L Russell <craig.russ...@oracle.com
>>> <mailto:craig.russ...@oracle.com>> wrote:
>>> Hi Sam,
>>>
>>>> On Jan 6, 2016, at 6:53 AM, Sam Ruby <ru...@intertwingly.net
>>>> <mailto:ru...@intertwingly.net>> wrote:
>>>>
>>>> Cool! This is the type of feedback I've been looking for!
>>>>
>>>> More inline.
>>>>
>>>> On Tue, Jan 5, 2016 at 5:06 PM, Craig L Russell
>>>> <craig.russ...@oracle.com <mailto:craig.russ...@oracle.com>> wrote:
>>>>> 1. When a message is selected, only the from:, to:, and subject: fields
>>>>> are displayed. The text of the message is not visible. This appears to be
>>>>> just in some cases, e.g. 2016-01-05T18:24:03Z and 2016-01-05T17:52:10Z .
>>>>
>>>> That was indeed a bug. Fixed.
>>>>
>>>>> 2. The left frame doesn't size correctly. It initially displays with a
>>>>> scroll bar at the bottom. If the vertical bar separating the data entry
>>>>> from the display is moved, the scroll bar still shows and the last few
>>>>> pixels in the fields are not visible.
>>>>
>>>> Odd. I don't see this with Safari, Firefox, or Chrome, all on a Mac.
>>>> Can you tell me what browser you are using, and perhaps send a screen
>>>> capture?
>>>
>>> MacOSX 10.10 Safari Version 9.0.2 (10601.3.9)
>>> see below. there is a horizontal scroll bar in the icla form.
>>>>
>>>>> 3. When File is pushed, 90 seconds later the alert comes up "stub for
>>>>> ICLA, filename: chaudhary--sunaina". Is it supposed to take over a minute
>>>>> to svn add /Users/clr/apache/documents/iclas/chaudhary--sunaina.pdf?
>>>>
>>>> What's happening here is:
>>>>
>>>> 1) cleanup/revert of any partial commits that may have failed.
>>> ok
>>>
>>>> 2) svn updates to retrieve the latest copy of both foundation/officers
>>>> and documents/iclas
>>>
>>> This is an unwelcome change from the way it works now. If it is a second or
>>> so, ok. But reloading the main page should svn update the repositories.
>>>
>>>> 3) svn add of the relevant document.
>>> ok
>>>
>>>>
>>>> Only #2 above should take a noticeable amount of time, particularly if
>>>> you haven't updated recently. On my machine, I'm seeing a total of 5
>>>> to 6 seconds average for the whole operation. Hopefully we should see
>>>> comparable or better times when this is deployed on whimsy-test.
>>>>
>>>> I may be able to eliminate one svn update. Of course, svn commit and
>>>> email need to be added, which will add to the elapsed time. Overall,
>>>> this should be no worse than the current workbench, and actually
>>>> should be a half-second or so per server interaction better. Note
>>>> that NOT displaying the svn commands as they are being executed
>>>> reduces the number of server interactions.
>>>
>>> But you could still save them and display them after they complete?
>>>>
>>>>> 4. When doing File a second time with the same document name, there is no
>>>>> error that there is already a document by that name. Only when I tried to
>>>>> svn rm the document did it give me the error. There is an error when
>>>>> doing a File with a document that is already in the repository.
>>>>
>>>> The previous (incomplete) commit is cleaned up first.
>>>
>>> It doesn't do a commit, just leaves the document as new in the repository.
>>> I hope the intent is to preserve the current work flow and have an explicit
>>> commit after file.
>>> And doing it a second time without a commit just overwrites the file. This
>>> might not be so bad because the filed document will disappear from the list
>>> of documents that can be processed.
>>> clr% svn rm robert-po-arickij/
>>> svn: E195006: Use --force to override this restriction (local modifications
>>> may be lost)
>>> svn: E195006:
>>> '/Users/clr/apache/documents/iclas/robert-po-arickij/icla.txt' has local
>>> modifications -- commit or revert them first
>>>
>>>>
>>>>> 5. I'd prefer the cursor to change to a "wait for response" instead of
>>>>> the slowly rotating clock.
>>>>
>>>> OK, done.
>>>
>>> When a document is being fetched (press the .pdf file name in the left
>>> area) can the cursor spin? It's not clear what is going on while the
>>> document loads into the right pane.
>>>>
>>>>> 6. It's not clear from the layout of the panel whether the pmc and
>>>>> podling fields are effective with the File button. Perhaps pmc and
>>>>> podling fields should be above the File button?
>>>>
>>>> The file button only updates iclas.txt and placed the pdf into
>>>> documents/iclas. The pmc and podling fields are only used for new
>>>> account requests.
>>>
>>> The current tool uses the pmc and podling fields to send emails on commit.
>>> So I'd still vote for having pmc and podling fields above the File button.
>>>>
>>>>> 7. The flow with the current tool is to fill all the fields, File,
>>>>> Commit, and then request account. What is the intent of the Request
>>>>> Account button on this screen?
>>>>
>>>> The proposed new flow is File (which will do a commit) then Request
>>>> Account (which is now a button).
>>>
>>> I like a separate Commit after File when I can look at the svn diff of the
>>> iclas.txt before commit.
>>>>
>>>>> 8. In the current tool, File brings up the svn commands that can be
>>>>> double checked for errors. The new tool should do something similar.
>>>>> There is an alert if there is a problem with an svn command but the
>>>>> current tool has a better way to present the problem, with the svn
>>>>> commands and then an alert to ask whether it should continue.
>>>>
>>>> I'll look at that in a subsequent pass.
>>>>
>>>>> 9. When filing a document with a digital signature, error: Exception:
>>>>> #<IOError: invalid filename: duncan-godwin>. It should be
>>>>> duncan-godwin/icla.txt and icla.txt.asc. But then I tried again and this
>>>>> time, success: stub for ICLA, filename: duncan-godwin. But sadly, only
>>>>> the .asc file was added.
>>>>
>>>> The first is a bug, and has been fixed.
>>>
>>> Agree. It's fixed.
>>>>
>>>> The second (only filing the .asc) may have occurred if you had
>>>> selected the asc file separately. To prevent this, I've now committed
>>>> a change which will no longer prompt you for the document type of
>>>> files ending in .asc or .sig.
>>>
>>> This is good.
>>>>
>>>>> 10. There should be a button to return to the main screen.
>>>>
>>>> Suggestion for where the button should go?
>>>
>>> Tippy top above "text".
>>>
>>>> Meanwhile, up arrow will
>>>> return you to the main screen.
>>>
>>> That works.
>>>>
>>>>> 11. The drag/drop of .jpg files doesn't appear to work. It should also
>>>>> display the convert commands that are being executed. And there doesn't
>>>>> appear to be an "undo" in case the drag/drop order was wrong. Drag/drop
>>>>> of pdf files works as expected.
>>>>
>>>> What problem are you seeing? If I go to "2015-12-19T17:50:43Z" and
>>>> drag "IMG_1119.JPG" and drop it on "IMG_1118.JPG", I get
>>>> "IMG_1118.png".
>>>
>>> I went to 2016-01-06T06:16:13Z and dragged image005.jpg onto image001.jpg
>>> and ended up with image001.pdf (good) but there is nothing in image001.pdf.
>>>
>>>>
>>>> Where should the convert commands be displayed?
>>>
>>> Whenever there is a message displayed, there should be a File: menu with
>>> operations, dup, spam, incomplete, processed, and unsigned buttons. Perhaps
>>> underneath the text, headers, raw section?
>>>
>>> Whenever there is a file displayed (image003.jpg) there should be a (Do)
>>> menu with burst, flip, etc. that applies to that specific file.
>>>
>>> Whenever there is a bad signature, there should be a menu with email
>>> button. The email should say "bad signature; please try again." I can give
>>> you the exact text from history.
>>> Whenever there is a missing public key, there should be a menu with email
>>> button. The email should say "unable to download public key."
>>>
>>> Right now, the document menu shows icla, grant, ccla, nda, and mem. This
>>> menu should only be for .pdf files and .txt files with matching .txt.asc
>>> files.
>>>
>>> Speaking of signed files, we often get Johnny-ICLA.pdf and
>>> Johnny-ICLA.pdf.asc. These should be renamed icla.pdf and icla.pdf.asc
>>> before being put into iclas/john-jacob-jingleheimer-schmidt. Same for
>>> johnny-icla.txt and johnny-icla.txt.asc.
>>>
>>>> At the moment, the
>>>> right pane will typically show the contents of the file being dragged
>>>> before the drop is complete, and will show the contents of the
>>>> combined file afterwards.
>>>
>>> I have not seen any of this behavior. All I see is the file being dragged
>>> changing the proposed drop target in a green oval. And dropping the file
>>> goes silent for a bit and then nothing appears in the right pane.
>>>>
>>>> A "right click" should bring up a menu that will burst a PDF.
>>>
>>> Do not like right click. Prefer to always have a menu (see above for
>>> suggestions).
>>>>
>>>>> 12. Once a mail has been processed, what should be the indication on the
>>>>> main page? How do I tell that there is new work to do?
>>>>
>>>> Like with the current secretary workbench, the idea is that once a
>>>> document is filed or deleted it will no longer show up in the main
>>>> index.
>>>
>>> Ok. This is fine.
>>>>
>>>> That may mean that with emails such as "2016-01-05T10:54:59Z", you
>>>> will need to file the ICLA and then delete the rest (either
>>>> individually via the context menu or collectively using
>>>> command-delete).
>>>
>>> Once I process the icla.pdf from that email, the rest of the stuff (random
>>> banners, vcf signatures, etc.) is still there, and I'm still looking at the
>>> same email.
>>>
>>> With this new work flow, the extra stuff isn't in svn so it doesn't need to
>>> be removed. But the email needs to be marked as complete. Maybe a
>>> "processed" button that tells the system that nothing else is needed for
>>> this email? Or "ignore" that is used for pure spam as well?
>>>
>>> Craig
>>>>
>>>>> Good progress.
>>>>
>>>> Thanks!
>>>>
>>>>> Craig
>>>
>>>>>
>>>>> Craig L Russell
>>>>> Architect, Oracle
>>>>> http://db.apache.org/jdo <http://db.apache.org/jdo>
>>>>> 408 276-5638 <tel:408%20276-5638> mailto:craig.russ...@oracle.com
>>>>> <mailto:craig.russ...@oracle.com>
>>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>> - Sam Ruby
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo <http://db.apache.org/jdo>
>>> 408 276-5638 <tel:408%20276-5638> mailto:craig.russ...@oracle.com
>>> <mailto:craig.russ...@oracle.com>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>> Craig L RussellArchitect, Oraclehttp://db.apache.org/jdo408 276-5638
>> mailto:craig.russ...@oracle.comp.S. A good JDO? O, Gasp!
>>
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!
