[TransWarp] Input wanted: Streams, Factories, sessions, etc.

[Ty Sarna]

> One of the big questions is where to put the interface definitions 
> themselves, though.  They don't quite fit under any of the ideas of 
> binding, naming, config, or even really storage!  Perhaps Ty's idea of 
> 'peak.networking' might make more sense, although even there it's an odd 
> one out when it comes to files.  The interfaces also don't seem ubiquitous 
> enough to deserve placement in peak.api.

Perhaps files would just stay under naming, then?

> For things like SMTP and other messaging interfaces, open() seems wrong, 
> since you don't really want a stream.  (Or do you?)  Perhaps it would make 
> more sense to call a 'session()' method for such kinds of objects, which 
> returns a session object that supports 'open()', but that open() would take 
> a different set of parameters than the usual.  For example, a SMTP 
> session's open() could take all the parameters of smtplib's 'sendmail()' 
> method, except for the actual message.

I think we would want to still support a sendmail() method on the
session too, for cases where you already have the complete message as a
string.

> * Should all messaging services (such as e-mail) be transactional?  (My 
> inclination is yes, for data integrity, Ty's inclination is no, for 
> simplicity.)

My inclination now is "both yes and no", I think.  Transactional
messaging is useful, but it can also be a pitfall.  I can easily see
writing code like this:

    storage.beginTransaction()

    try:
	...
        if 1+1 != 2:
            raise UniverseError, "Rules of math have changed!"
        ...
    except UniverseError:
        # Whoa! We need to page the on-call Quantum Mechanic to
        # investigate...
        SendShortMail('KL5-6832', 'Check universe and restart if needed')
        storage.abortTransaction()
        sys.exit(42)

    ...    

"Oops!"

Now, certainly CTAP and you could create another TransactionService,
etc.  But messaging about abort-worthy errors seems like a fairly common
use case, so I'm thinking that perhaps session() should take a parameter
indicating immediate/non-transacted mode, for situations such as these. 

Also, in writing the above, I'm thinking that maybe we should make the
convenience functions a bit more convenient, and change them to
storage.beginTxn, etc. We already use the "txn" abreviation elsewhere
(txnTime, joinTxn, etc), and it shouldn't cause much/any pain to anyone
if we change it now, before anyone is really using it...