|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Don jessup (djessup72, yahoo dot com) Date: 2001.09.28 - 10.15 MDT
True. But, I think this would be applicable to many more cases then video. Say for instance Word documents, power point presentations, Adobe docs, Visio documents, acsii text, html, c, C++, excel, jpeg.... . Maybe we even should have a attribute that identifies a document as streamable or not based on it's extenstion. Well, maybe this is a 2nd generation type of thing but at least we should keep it in mind. --- Perry Merritt <perry, merrittclan dot com> wrote: > Unless of course the user tries to start reading > random locations in the file. > > If you extend your idea to try to have partial video > streams on disk and backfill them from tape, it > seems like a plausible idea. It would also mean we'd > have to keep track of how much is actually written > to disk at any point in time. > > > > -----Original Message----- > From: Don jessup djessup72, yahoo dot com > Sent: Fri, 28 Sep 2001 08:25:54 -0700 (PDT) > To: antera, cryptofreak dot org > Subject: Re: Meeting thoughts and some other stuff. > > > Here is another reason I like going thru the portal > on > restore. > We could unblock the open almost immediatly and > stream the data to disk and to the user at the > same > time. > > Here are those documents again. > > --- Perry and Lorae Merritt > <plmerritt, hypermall dot net> > wrote: > > For ADC security, can't we just validate that the > > UID asking about a file or > > trying to modify a file has permission to the > file? > > Essentially we'd just > > tie into the OS/file system security that already > > exists (UID/GID). > > > > ----- Original Message ----- > > From: "Jay Miller" <jnmiller, cryptofreak dot org> > > To: <antera, cryptofreak dot org> > > Sent: Thursday, September 27, 2001 9:28 PM > > Subject: Re: Meeting thoughts and some other > stuff. > > > > > > > - Words by Perry and Lorae Merritt > > <plmerritt, hypermall dot net> [010927 > > 05:19]: > > > > Don't start with me? I never planned to stop > > with you. > > > > > > Careful - I'll tell my girlfriend to stop > talking > > to you! (I bought her > > > a laptop.. what did YOU buy her? :) > > > > > > > During the meeting you can tell me again(?) > how > > you plan on moving the > > data > > > > from the restore operation through the ADML to > > the fileystem. Are you > > > > thinking you're going to send it through the > > portal/ioclt interface? If > > so, > > > > how are you going to get it from the restore > > that is doing file writes? > > > > > > Pipes, I suppose. Instead of writing to a > normal > > file descriptor, we > > > write to stdin and parse the incoming stream for > > the raw data. We might > > > also be able to do some verification on file > > metadata to make sure the > > > two copies (one of which should be of zero-size) > > are of one another. > > > Anyway, once we know what the raw data is (we > > don't really need the > > > metadata), we cram it through the portal to the > > kernel and do standard > > > write() calls. > > > > > > Sounds pretty clean..? > > > > > > > It seems to me that if we don't expose our > > internal mechanism for > > figuring > > > > out who's doing the open and subsequent > writes, > > the opportunity for > > someone > > > > wanting to break our system should be fairly > > narrow. In fact, whats to > > stop > > > > them from writting their own ADC and doing > > whatever they want as it is? > > > > > > Security through of obscurity? Perry, you > should > > know better than to > > > propose a scheme like that to me! > > > > > > (http://www.loktechnology.com/encryption.html) > > > > > > The nice thing about communication with the ADML > > being kept to only > > > pieces we write is the ability to have both > sides > > manage the > > > 'connection'. We are able to negotiate security > > protocols this way. > > > Giving messages to our kernel module 'from the > > top', as it were, makes > > > it much harder to know who's talking to us. > > > > > > Your point about rogue ADC's is actually a very > > good one to bring up and > > > keep in mind. The idea that this software setup > > could be running on > > > some companies' "master server" implies that > > hostile actions might be > > > attempted against our stuff. Access to the > ADML, > > after all, entails > > > access to anything in the system, including all > > file data. Any actual > > > product should probably account for this. Dan, > > you might wish to think > > > about this from a sales perspective, too: we're > > essentially making a back > > > door into the kernel - something many admins > might > > be hesitant about..? > > > > > > Right. > > > > > > Now, here's the interesting and (I thought) > > radical idea we came across > > > today: no PD. We've mentioned a lot that the > ADML > > layer is just a > > > flexible way to implement extended attributes > > (EAs). And we're planning > > > on never actually deleting the file itself from > > the FS - just the > > > metadata. So why not utilize that data > structure > > to store our own data? > > > > > > The PDM would still be responsible for managing > > that stuff, and we might > > > need to manage some kind of hash or some other > > quick structure for > > > searching the EAs (for high UEFs, or > whatever..). > > > > > > Neat idea? > > > > > > I love simplifying things.. > > > > > > -- > > > Jay Miller > > > > > > ICQ: 32123421 | YM: ladenedge | > > http://www.cryptofreak.org > > > PGP: 0xedc9bb8d | 41a6428c 46abd36b 6b259b68 > > 8a28ca4c edc9bb8c > > > -- > > > This is the antera mailing list. To > unsubscribe, > > email > > > majordomo, cryptofreak dot org with message body > > `unsubscribe antera'. > > > Or, for more information, visit > > http://www.cryptofreak.org/. > > > > > > > -- > > This is the antera mailing list. To unsubscribe, > > email > > majordomo, cryptofreak dot org with message body > > `unsubscribe antera'. > > Or, for more information, visit > http://www.cryptofreak.org/. > > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com > > > ___________________________________________________________________________ > Visit http://www.visto.com. > Find out how companies are linking mobile users to > the > enterprise with Visto. > > === message truncated === __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com -- This is the antera mailing list. To unsubscribe, email majordomo, cryptofreak dot org with message body `unsubscribe antera'. Or, for more information, visit http://www.cryptofreak.org/.
This archive was generated by hypermail 2b30 : 2001.09.29 - 03.00 MDT |
