[Appeal] sharing, tenor, content manager

[Aaron J. Seigo]

On Monday 18 April 2005 04:24, Jan Muehlig wrote:
> The challenge then is to find an intuitive, flexible and reliable way to
> define what the others "see". What pops in mind is a kind of border,
> domain border, that let's through only certain things. A kind of
> firewall. The Tenor firewall. In its most rigid mode, it razors down
> everything except for the things inside the object (file). It is simply
> not transported through the firewall.

this is something that can be added on to an existing system, but which i 
think will be very hard to define the needs of until we see what kinds of 
information end up in the tenor system. IOW, i think it's simply too early to 
say. it's good to put it on the map as a question to solve, but the solution 
exists in the future at this point.

the easiest solution is to not ship metadata around unless specifically 
requested and put the onus on the receiver to re-index it. if you send me 
something via email, then my context with the document starts with that 
interaction anywyas; i may not need nor want your contextual information.

but again, that's hard to say with out some test data to play with.

> I am no expert in security concepts, so I can't go deeper here.

this is a privacy issue, which relates to the sharing or concealing of 
sensitive information, not a security issue. "security" has well defined 
meanings in the software world, and the last thing i want to hear is that 
tenor "has security issues" when really it's an issue of handling privacy ... 
saying it's a security issue in public would destroy its credibility and do 
tremendous damage to the concept as the public would get the impression tenor 
could be used to compromise your computer. =/

> But what 
> is obvious is that we come to a compatibility issue. If I
> transport/share my objects together with well defined meta data from one
> system to the other (let's say a Tenor enabled system to a Gnome
> system), what happens with the meta data?

worst case is that you are back to the old filesystem-only approach.

> Standards? 

we can define standards once we have something to define, i think =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20050418/c4b169de/attachment.pgp