blob: ae07add85d94b222fefc554d7c875e326bcfb74e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
- Service and message names should be more carefully restricted;
they should have a max length, may not be an empty string,
and perhaps should not be allowed to be a glob such as "*" since
the config file could conveniently use such notation.
Suggest requiring length > 0, length < max,
name contains at least one ".", no initial ".", and valid UTF-8.
That would prohibit plain "*" but not "foo.bar.baz.operator*"
For maximum convenience from all programming languages, we could go
further and just categorically ban nearly all non-alphanumeric
characters.
- Message matching rules (so broadcasts can be filtered) need sorting
out.
- How we will handle DCOP needs sorting out. Among other things, we
need to check that service and service-ownership semantics map to DCOP
reasonably well.
- Activation needs some careful additional thinking-through.
- Recursive/composite/etc. types and associated API, see mailing list.
- Configuration file (working on that now)
- Property list feature on message bus (list of properties associated
with a connection). May also include message matching rules
that involve the properties of the source or destination
connection.
- Implement all the needed resource limits to keep clients from
killing the message bus.
- Automatic service activation, should probably be done through a message flag.
- Disconnecting the remote end on invalid UTF-8 is probably not a good
idea. The definitiion of "valid" is slightly fuzzy. I think it might
be better to just silently "fix" the UTF-8, or perhaps return an error.
- We might consider returning a "no such operation" error in dbus-connection.c
for unhandled messages.
|
