THIS SPECIFICATION IS IN PROGRESS DO NOT READ IT.

{{wrongtitle|title=Asynchronous File I/O}}

Problem

Twisted has no API for asynchronous file I/O. It oughtta.

Solution

def FilePath.openAsynchronously()
    """
    @return: AsynchronousFileIOLayer.
    """


def AsynchronousFileIOLayer.read(consumer, start=0, end=None)
    """
    @param consumer: IFilePathConsumer provider.
    @param start: The byte offset into the file at which to start producing.
    @param end: The byte offset into the file at which to stop
        producing, or None to indicate the end of the file.
    @return: None
    """


def AsynchronousFileIOLayer.write(producer, start=0)
    """
    @param producer: IFilePathProducer provider. Its produceTo method
        will be called.
    @param start: The byte offset into the file at which to start writing. [what about appending?]
    @return: None.
    """



interface IFilePathConsumer:
    """
    A consumer of data. Code which calls methods on this interface
    should call consumeFrom(p), followed by zero or more calls to
    write(d), followed by finished(r). Implementors should expect
    such.
    """
    def consumeFrom(producerRegulator):
        """
        Get ready to receive data.
        @param producerRegulator: The provider of L{IProducerRegulator}
            which can be used to control the production of data.
        """
        


    def write(data):
        """
        Handle incoming data.
        """
        


    def finished(reason):
        """
        @param reason: An instance of L{Failure} or None. If it's None
            then everything's great.  Otherwise it's a failure
            describing the problem.
        """
        





interface IFilePathProducer:
    """
    A thing what has data to send.
    """
    def produceTo(consumer):
        """
        Start sending data to the given consumer.

        @param consumer: The IFilePathConsumer to which data should be
            sent.

        An appopriate L{IProducerRegulator} must be created and passed
        to the consumer's L{consumeFrom

Open Issues

Should produceTo and consumeFrom return Deferreds? If they do, it is important to note this means there will be duplicate completion notifications between the deferred and the .finished method. The order these are called in should perhaps be well-defined.

What about appending to a file? Should there be a special value passable as the 'start' parameter to write to indicate that the file should be appended to?

Punchline

The astute reader will notice that this is actually a redesign of the producer/consumer framework.