~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/smart/__init__.py

• browse files at revision 6046.1.1
• compare with another revision
• download diff
• download tarball
• view history from revision 6046.1.1

• reverse the comparison (6046.1.1 to 0.17.26)
• stop comparing with revision 0.17.26

Show diffs side-by-side

added

removed

bzrlib/smart/__init__.py

 

1

# Copyright (C) 2006 Canonical Ltd

 

2

#

 

3

# This program is free software; you can redistribute it and/or modify

 

4

# it under the terms of the GNU General Public License as published by

 

5

# the Free Software Foundation; either version 2 of the License, or

 

6

# (at your option) any later version.

 

7

#

 

8

# This program is distributed in the hope that it will be useful,

 

9

# but WITHOUT ANY WARRANTY; without even the implied warranty of

 

10

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 

11

# GNU General Public License for more details.

 

12

#

 

13

# You should have received a copy of the GNU General Public License

 

14

# along with this program; if not, write to the Free Software

 

15

# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

 

16

 

 

17

"""Smart-server protocol, client and server.

 

18

 

 

19

This code is fairly complex, so it has been split up into a package of modules,

 

20

rather than being a single large module.  Refer to the individual module

 

21

docstrings for details.

 

22

 

 

23

Server-side request handlers are registered in the `bzrlib.smart.request`

 

24

module.

 

25

 

 

26

The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,

 

27

and so on.

 

28

 

 

29

There is also an plain file-level transport that calls remote methods to

 

30

manipulate files on the server in `bzrlib.transport.remote`.

 

31

 

 

32

The protocol is described in doc/developers/network-protocol.txt.

 

33

 

 

34

"""

 

35

 

 

36

# TODO: _translate_error should be on the client, not the transport because

 

37

#     error coding is wire protocol specific.

 

38

 

 

39

# TODO: A plain integer from query_version is too simple; should give some

 

40

# capabilities too?

 

41

 

 

42

# TODO: Server should probably catch exceptions within itself and send them

 

43

# back across the network.  (But shouldn't catch KeyboardInterrupt etc)

 

44

# Also needs to somehow report protocol errors like bad requests.  Need to

 

45

# consider how we'll handle error reporting, e.g. if we get halfway through a

 

46

# bulk transfer and then something goes wrong.

 

47

 

 

48

# TODO: Make each request and response self-validatable, e.g. with checksums.

 

49

#

 

50

# TODO: get/put objects could be changed to gradually read back the data as it

 

51

# comes across the network

 

52

#

 

53

# TODO: What should the server do if it hits an error and has to terminate?

 

54

#

 

55

# TODO: is it useful to allow multiple chunks in the bulk data?

 

56

#

 

57

# TODO: If we get an exception during transmission of bulk data we can't just

 

58

# emit the exception because it won't be seen.

 

59

#   John proposes:  I think it would be worthwhile to have a header on each

 

60

#   chunk, that indicates it is another chunk. Then you can send an 'error'

 

61

#   chunk as long as you finish the previous chunk.

 

62

#

 

63

# TODO: Clone method on Transport; should work up towards parent directory;

 

64

# unclear how this should be stored or communicated to the server... maybe

 

65

# just pass it on all relevant requests?

 

66

#

 

67

# TODO: Better name than clone() for changing between directories.  How about

 

68

# open_dir or change_dir or chdir?

 

69

#

 

70

# TODO: Is it really good to have the notion of current directory within the

 

71

# connection?  Perhaps all Transports should factor out a common connection

 

72

# from the thing that has the directory context?

 

73

#

 

74

# TODO: The server that manages a connection should be quite small and retain

 

75

# minimum state because each of the requests are supposed to be stateless.

 

76

# Then we can write another implementation that maps to http.

 

77

#

 

78

# TODO: What to do when a client connection is garbage collected?  Maybe just

 

79

# abruptly drop the connection?

 

80

#

 

81

# TODO: Server in some cases will need to restrict access to files outside of

 

82

# a particular root directory.  LocalTransport doesn't do anything to stop you

 

83

# ascending above the base directory, so we need to prevent paths

 

84

# containing '..' in either the server or transport layers.  (Also need to

 

85

# consider what happens if someone creates a symlink pointing outside the

 

86

# directory tree...)

 

87

#

 

88

# TODO: Server should rebase absolute paths coming across the network to put

 

89

# them under the virtual root, if one is in use.  LocalTransport currently

 

90

# doesn't do that; if you give it an absolute path it just uses it.

 

91

#

 

92

# XXX: Arguments can't contain newlines or ascii; possibly we should e.g.

 

93

# urlescape them instead.  Indeed possibly this should just literally be

 

94

# http-over-ssh.

 

95

#

 

96

# TODO: Probably want some way for server commands to gradually produce body

 

97

# data rather than passing it as a string; they could perhaps pass an

 

98

# iterator-like callback that will gradually yield data; it probably needs a

 

99

# close() method that will always be closed to do any necessary cleanup.

 

100

 

 

101

 

 

102

# Promote some attributes from submodules into this namespace

 

103

from bzrlib.smart.request import SmartServerRequestHandler

 

104

 

 

105

 

• Older »

Loggerhead is a web-based interface for Breezy
Version: 2.0.1