Wirefeed vs SyndFeed etc
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Wirefeed vs SyndFeed etc
by Nick Lothian
::
Rate this Message:
One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments)
One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). What do people think? Is there something I'm missing here? Nick IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Wirefeed vs SyndFeed etc
by Robert (kebernet) Cooper
::
Rate this Message:
.originalWireFeed() +1
On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian <nlothian@...> wrote: > One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) > > One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) > > This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. > > The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). > > What do people think? Is there something I'm missing here? > > Nick > > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Wirefeed vs SyndFeed etc
by Robert (kebernet) Cooper
::
Rate this Message:
Actually, let me amend that...
I would make is something more like SyndFeedImpl( WireFeed, boolean preserveWireFeed) with .orginalWireFeed() optionally returning null. Rome is already pretty RAM beefy. If you don't want the source wire feed, we should definitely let it fall away. On Tue, Feb 24, 2009 at 9:44 PM, Robert kebernet Cooper <kebernet@...> wrote: > .originalWireFeed() +1 > > On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian > <nlothian@...> wrote: >> One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) >> >> One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) >> >> This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. >> >> The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). >> >> What do people think? Is there something I'm missing here? >> >> Nick >> >> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > > > > -- > :Robert "kebernet" Cooper > ::kebernet@... > Alice's cleartext > Charlie is the attacker > Bob signs and encrypts > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Wirefeed vs SyndFeed etc
by Robert (kebernet) Cooper
::
Rate this Message:
Ammend again --
This would be a bigger change, but would SyndEntry.wireEntry() make sense too? On Tue, Feb 24, 2009 at 9:46 PM, Robert kebernet Cooper <kebernet@...> wrote: > Actually, let me amend that... > > I would make is something more like SyndFeedImpl( WireFeed, boolean > preserveWireFeed) with .orginalWireFeed() optionally returning null. > > Rome is already pretty RAM beefy. If you don't want the source wire > feed, we should definitely let it fall away. > > On Tue, Feb 24, 2009 at 9:44 PM, Robert kebernet Cooper > <kebernet@...> wrote: >> .originalWireFeed() +1 >> >> On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian >> <nlothian@...> wrote: >>> One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) >>> >>> One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) >>> >>> This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. >>> >>> The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). >>> >>> What do people think? Is there something I'm missing here? >>> >>> Nick >>> >>> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> >> >> >> -- >> :Robert "kebernet" Cooper >> ::kebernet@... >> Alice's cleartext >> Charlie is the attacker >> Bob signs and encrypts >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 >> > > > > -- > :Robert "kebernet" Cooper > ::kebernet@... > Alice's cleartext > Charlie is the attacker > Bob signs and encrypts > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: Wirefeed vs SyndFeed etc
by Nick Lothian
::
Rate this Message:
That would be ideal.
It would be a quite a lot bigger set of changes, though (and I'm still hoping to get 1.0 out sometime soon..). A superficial assessment would indicate we'd need to change ConverterForRSS090 ConverterForAtom10 ConverterForAtom03 but that's without trying to work out how we'd pass the preserveWireFeed flag around - which I also think is a good idea. Nick -----Original Message----- From: Robert "kebernet" Cooper [mailto:kebernet@...] Sent: Wednesday, 25 February 2009 1:37 PM To: dev@... Subject: Re: Wirefeed vs SyndFeed etc Ammend again -- This would be a bigger change, but would SyndEntry.wireEntry() make sense too? On Tue, Feb 24, 2009 at 9:46 PM, Robert kebernet Cooper <kebernet@...> wrote: > Actually, let me amend that... > > I would make is something more like SyndFeedImpl( WireFeed, boolean > preserveWireFeed) with .orginalWireFeed() optionally returning null. > > Rome is already pretty RAM beefy. If you don't want the source wire > feed, we should definitely let it fall away. > > On Tue, Feb 24, 2009 at 9:44 PM, Robert kebernet Cooper > <kebernet@...> wrote: >> .originalWireFeed() +1 >> >> On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian >> <nlothian@...> wrote: >>> One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) >>> >>> One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) >>> >>> This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. >>> >>> The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). >>> >>> What do people think? Is there something I'm missing here? >>> >>> Nick >>> >>> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> >> >> >> -- >> :Robert "kebernet" Cooper >> ::kebernet@... >> Alice's cleartext >> Charlie is the attacker >> Bob signs and encrypts >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 >> > > > > -- > :Robert "kebernet" Cooper > ::kebernet@... > Alice's cleartext > Charlie is the attacker > Bob signs and encrypts > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. |
|
|
Re: Wirefeed vs SyndFeed etc
by Robert (kebernet) Cooper
::
Rate this Message:
Yeah, I definitely agree on getting something called 1.0 out :D
I know Alejandro has a "2.0" outline. I have a "1.5" outline on my machine that is 1.5+ syntax and Stax based with a completely different module format. Still, we haven't shipped a 1.0 version yet in spite of the uber-stability of the library at this point. If you think you can get something in that generally meets your needs and doesn't break binary compat with the current libs, I would say have at it. I, for one, would kind of like to ship the current code so I can start looking at different code. On Tue, Feb 24, 2009 at 11:07 PM, Nick Lothian <nlothian@...> wrote: > That would be ideal. > > It would be a quite a lot bigger set of changes, though (and I'm still hoping to get 1.0 out sometime soon..). > > A superficial assessment would indicate we'd need to change > > ConverterForRSS090 > ConverterForAtom10 > ConverterForAtom03 > > but that's without trying to work out how we'd pass the preserveWireFeed flag around - which I also think is a good idea. > > Nick > > -----Original Message----- > From: Robert "kebernet" Cooper [mailto:kebernet@...] > Sent: Wednesday, 25 February 2009 1:37 PM > To: dev@... > Subject: Re: Wirefeed vs SyndFeed etc > > Ammend again -- > > This would be a bigger change, but would SyndEntry.wireEntry() make sense too? > > On Tue, Feb 24, 2009 at 9:46 PM, Robert kebernet Cooper > <kebernet@...> wrote: >> Actually, let me amend that... >> >> I would make is something more like SyndFeedImpl( WireFeed, boolean >> preserveWireFeed) with .orginalWireFeed() optionally returning null. >> >> Rome is already pretty RAM beefy. If you don't want the source wire >> feed, we should definitely let it fall away. >> >> On Tue, Feb 24, 2009 at 9:44 PM, Robert kebernet Cooper >> <kebernet@...> wrote: >>> .originalWireFeed() +1 >>> >>> On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian >>> <nlothian@...> wrote: >>>> One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) >>>> >>>> One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) >>>> >>>> This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. >>>> >>>> The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). >>>> >>>> What do people think? Is there something I'm missing here? >>>> >>>> Nick >>>> >>>> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>>> >>> >>> >>> >>> -- >>> :Robert "kebernet" Cooper >>> ::kebernet@... >>> Alice's cleartext >>> Charlie is the attacker >>> Bob signs and encrypts >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 >>> >> >> >> >> -- >> :Robert "kebernet" Cooper >> ::kebernet@... >> Alice's cleartext >> Charlie is the attacker >> Bob signs and encrypts >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 >> > > > > -- > :Robert "kebernet" Cooper > ::kebernet@... > Alice's cleartext > Charlie is the attacker > Bob signs and encrypts > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Wirefeed vs SyndFeed etc
by John M-7
::
Rate this Message:
I think this is a good idea. I'd like to be able to get at the "raw" contents of the underlying feed.
-John M On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian <nlothian@...> wrote: One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) |
|
|
Re: Wirefeed vs SyndFeed etc
by Alejandro Abdelnur-2
::
Rate this Message:
Catching a plane now, i'll send out my 2.0 outline next week.
On Wed, Feb 25, 2009 at 9:52 AM, Robert kebernet Cooper <kebernet@...> wrote: Yeah, I definitely agree on getting something called 1.0 out :D |
|
|
RE: Wirefeed vs SyndFeed etc
by Nick Lothian
::
Rate this Message:
I've just committed the changes for this.
If you'd like to test this (please do!), jars are available in https://rome.dev.java.net/servlets/ProjectDocumentList?folderID=11069&expandFolder=11069&folderID=11069 WireFeeds will be preserved if the property preserveWireFeed is set on the SyndFeedInput object it is built from: SyndFeedInput in = new SyndFeedInput(); in.setPreserveWireFeed(true); SyndFeed syndFeed = in.build(..); WireFeed wireFeed = syndFeed.originalWireFeed(); Atom/RSS Entry/Item objects are also available from SyndEntry objects if the WireFeed is preserved: Object obj = syndEntry.getWireEntry(); if (obj != null && obj instanceof Entry) { // it is an Atom Entry object // do Atom specific stuff, eg: Entry entry = (Entry) o; System.out.println(entry.getRights()); } else if (obj != null && obj instanceof Item) { // it is a RSS Item object // do RSS specific stuff eg: Item item = (Item) o; System.out.println(item.getComments()); } The Fetcher can be set to preserve WireFeeds by setting the preserveWireFeed property to true: feedFetcher.setPreserveWireFeed(true); I've committed unit tests for all of this, and re-enabled a large number of tests which had previously been commented out. Nick -----Original Message----- From: Nick Lothian [mailto:nlothian@...] Sent: Wednesday, 25 February 2009 2:37 PM To: dev@... Subject: RE: Wirefeed vs SyndFeed etc That would be ideal. It would be a quite a lot bigger set of changes, though (and I'm still hoping to get 1.0 out sometime soon..). A superficial assessment would indicate we'd need to change ConverterForRSS090 ConverterForAtom10 ConverterForAtom03 but that's without trying to work out how we'd pass the preserveWireFeed flag around - which I also think is a good idea. Nick -----Original Message----- From: Robert "kebernet" Cooper [mailto:kebernet@...] Sent: Wednesday, 25 February 2009 1:37 PM To: dev@... Subject: Re: Wirefeed vs SyndFeed etc Ammend again -- This would be a bigger change, but would SyndEntry.wireEntry() make sense too? On Tue, Feb 24, 2009 at 9:46 PM, Robert kebernet Cooper <kebernet@...> wrote: > Actually, let me amend that... > > I would make is something more like SyndFeedImpl( WireFeed, boolean > preserveWireFeed) with .orginalWireFeed() optionally returning null. > > Rome is already pretty RAM beefy. If you don't want the source wire > feed, we should definitely let it fall away. > > On Tue, Feb 24, 2009 at 9:44 PM, Robert kebernet Cooper > <kebernet@...> wrote: >> .originalWireFeed() +1 >> >> On Tue, Feb 24, 2009 at 9:21 PM, Nick Lothian >> <nlothian@...> wrote: >>> One of the complications of working with ROME is the distinction between SyndFeed and Wirefeed, and the loss of data once you have a SyndFeed. For example, the Fetcher always returns a SyndFeed, which makes it impossible to get at any underlying data (eg, RSS comments) >>> >>> One possible way around this would be if SyndFeed.createWireFeed() returned the original WireFeed (or alternatively we create a method SyndFeed.orginalWireFeed() or something to do the same thing) >>> >>> This would appear a fairly minor change. We'd need to modify the SyndFeedImpl(WireFeed feed) constructor to set a private WireFeed field, and then modify the createWireFeed method to return it. >>> >>> The only downside that I can think of is that any changes to the SyndFeed wouldn't be reflected in the WireFeed (which may be a good argument to create a new SyndFeed.orginalWireFeed() method as a name like that would make it quite clear what you are getting). >>> >>> What do people think? Is there something I'm missing here? >>> >>> Nick >>> >>> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> >> >> >> -- >> :Robert "kebernet" Cooper >> ::kebernet@... >> Alice's cleartext >> Charlie is the attacker >> Bob signs and encrypts >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 >> > > > > -- > :Robert "kebernet" Cooper > ::kebernet@... > Alice's cleartext > Charlie is the attacker > Bob signs and encrypts > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 > -- :Robert "kebernet" Cooper ::kebernet@... Alice's cleartext Charlie is the attacker Bob signs and encrypts http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of Education.au except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. |
| Free embeddable forum powered by Nabble | Forum Help |
