D.L. Tooley | 4 Aug 2003 18:31
Picon

RSS and Chandler

Has anyone considered using Dave Winer’s RSS in Chandler?  Integrating e-mail with web or blog postings would improve the functionality of both – as long as those e-mailed are getting stuff they want to receive.  RSS and the central calendar function of Chandler would also have some interesting synergies for public and semi-public events.

 

I’m just a clueless lurker here, but there would seem to be some synergy, and Winer’s probably looking for friends right now.

 

-D.L.

Hamish Harvey | 4 Aug 2003 20:10
Picon
Picon
Favicon

Re: RSS and Chandler

On Monday 04 Aug 2003 5:31 pm, D.L. Tooley wrote:
> Has anyone considered using Dave Winer's RSS in Chandler?  Integrating
> e-mail with web or blog postings would improve the functionality of both
> - as long as those e-mailed are getting stuff they want to receive.  RSS
> and the central calendar function of Chandler would also have some
> interesting synergies for public and semi-public events.
>
> I'm just a clueless lurker here, but there would seem to be some
> synergy, and Winer's probably looking for friends right now.

[Disclaimer: I am not an expert in RDF, RSS, or Chandler.  These are just 
thought triggered by D.L.'s comments.]

From the comment about friends one might deduce that you are aware of the 
rather unseemly ongoing brawl between the advocates of different syndication 
standards.  Some things to bear in mind:

* I believe that the Chandler data store is to be RDF based.  This would lead 
logically to the RDF based RSS 1.0, which is not Winer's version.

* RSS 2.0, Winer's version, is extensible but not as flexible as RSS 1.0.  
Both it and the new syndication standard, Echo or Not Echo or Pie or Not Pie 
or Atom or Not Atom or whatever, is very much focused on weblog syndication.

http://www.xml.com/pub/a/2003/07/23/rssone.html

That having been said I am very keen on RSS and it would be great to see RSS 
consumption and production in Chandler.  Since all the RSS formats are 
essentially very simple it should be possible to include a facility for 
generating RSS of a version or feeds of the new format - whatever it is 
called in the end - from data stored in the Chandler data store.

It is interesting to note that the Google search for "Chandler RSS" returns 
more or less every weblog in which Chandler is mentioned because more or less 
every weblog includes the word RSS.  The first result however is relevant:

http://blog.kowalczyk.info/archives/000444.html

That post doesn't try to justify the belief that, "the future lies in ... one 
application to manage various kinds of information."  One thing which could - 
I think should - be implement in Chandler is persistent storage for incoming 
RSS news.  I'd like to be able to easily categorise and keep information from 
RSS feeds.  This categorisation should be common across Chandler, so that I 
can quickly attach news items, e-mails, and any other items in the Chandler 
data store to, for example, a project entry.  Of course news items in RSS 
feeds which are not specifically linked to other data or in some other way 
marked for keeping should not be kept.

It hadn't occurred to me before, but the combination of RDF based RSS 1.0 and 
RDF based Chandler is potentially extraordinarily powerful.  Mappings could 
be created between other versions of RSS or any new standard but presumably 
not as readily as between the data in RSS 1.0 feeds which is already in RDF 
form.  While information from weblogs in RSS form can be stored in the 
Chandler data store as a blob, RDF data in RSS feed could be rooted into the 
store according to some schema.

The above link to XML.com discusses the use of RSS 1.0 in providing feeds of 
information on new articles in scientific journals.  Combined with a Chandler 
component for managing bibliographic data, a few keystrokes could categorise 
and store a bibliographic record for a new paper.  With this feature Chandler 
could wipe the floor with EndNote in usability terms. If Chandler was in 
widespread use in academia, general publishers could be persuaded to provide 
links in online search results which would return those results in the same 
RSS format, allowing easy incorporation in a user's bibliographic database.

Enough rambling,
Hamish

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Kaitlin Duck Sherwood | 4 Aug 2003 22:21
Favicon

Re: RSS and Chandler

D.L. Tooley wrote:

> Has anyone considered using Dave Winer’s RSS in Chandler? Integrating 
> e-mail with web or blog postings would improve the functionality of 
> both – as long as those e-mailed are getting stuff they want to 
> receive. RSS and the central calendar function of Chandler would also 
> have some interesting synergies for public and semi-public events.
>
We do have an RSS aggregator in Chandler now (ZaoBao), though we haven't

put a lot of effort into it. (Chao wrote it as a hobby project.)

We are aware of RSS and think it's a good idea, but we're focused on 
different things at the moment.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

andy.glew | 11 Aug 2003 17:56
Picon
Favicon

Personal vs Work Computing Services (Calendaring)

-- Main.AndyGlew - 11 Aug 2003

(Extracted from a post to comp.arch;
will also be cross posted to the mailing list;
and to the Chandler wiki.)

Things like calendaring are not a corporate service.
They are a personal computing service that needs to interface
to the corporate calendaring system, as well as to the 
calendaring system for other individuals not necessarily part
of the compay.

The individual wants to have a single calendar.  This calendar
will probably include his work calendar, but may also have
visibility to his wife's calendar, that of the local soccer league
and PTA, etc.  

It's not simply a question of having a personal calendar 
for non-work hours and a work calendar for work hours.
You may, for example, want to schedule a work phone meeting
in the middle of your personal vacation, but you had better
make sure that it doesn't overlap with your daughter's recital.
(Or with your plane travel, as recently happened to me,
not taking account of timezones properly.)

It's not simply a question of storing the user's
calendar data on the corporate server: some parts of the user
calendar may want to be kept private from the employer,
such as:
   * job interviews with other companies
   * work for other companies - for the increasingly large 
      fraction of the workforce that are consultants or contractors

More and more, the individual is computer augmented.
The individual needs access to these personal computer
services at the workplace.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

D.L. Tooley | 12 Aug 2003 01:46
Picon

RE: Design digest, Vol 1 #259 - 1 msg

Creating groups for calendaring purposes is important, just as it is for
e-mail.  But don't forget that calendaring can also be important to
managing groups.  

For instance you might want to cc: your wife on an anticipated flight
plan at the same time you schedule the meeting with a client - and also
scheduling notification for your flight reservation and a company
calendar for a later date.  If the wife doesn't disagree than those
'e-mail' notifications could be sent on a 'calendared' event.

Similiarly one might want to schedule a personal PR release to go out at
different times.  For example the first notice of your promotion or
resignation could go to your family and co-workers - this could then be
followed by a company posting, followed by 'publication' in an industry
mag - and if you are big enough by a RSS feed or even Usenet!

-D.L.

-----Original Message-----
From: design-admin <at> osafoundation.org
[mailto:design-admin <at> osafoundation.org] On Behalf Of
design-request <at> osafoundation.org
Sent: Monday, August 11, 2003 10:00 AM
To: design <at> osafoundation.org
Subject: Design digest, Vol 1 #259 - 1 msg

Send Design mailing list submissions to
	design <at> osafoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.osafoundation.org/mailman/listinfo/design
or, via email, send a message with subject or body 'help' to
	design-request <at> osafoundation.org

You can reach the person managing the list at
	design-admin <at> osafoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Design digest..."

Today's Topics:

   1. Personal vs Work Computing Services (Calendaring)
(andy.glew <at> amd.com)

--__--__--

Message: 1
From: andy.glew <at> amd.com
To: design <at> osafoundation.org
Date: Mon, 11 Aug 2003 08:56:59 -0700
Subject: [Design] Personal vs Work Computing Services (Calendaring)

-- Main.AndyGlew - 11 Aug 2003

(Extracted from a post to comp.arch;
will also be cross posted to the mailing list;
and to the Chandler wiki.)

Things like calendaring are not a corporate service.
They are a personal computing service that needs to interface
to the corporate calendaring system, as well as to the 
calendaring system for other individuals not necessarily part
of the compay.

The individual wants to have a single calendar.  This calendar
will probably include his work calendar, but may also have
visibility to his wife's calendar, that of the local soccer league
and PTA, etc.  

It's not simply a question of having a personal calendar 
for non-work hours and a work calendar for work hours.
You may, for example, want to schedule a work phone meeting
in the middle of your personal vacation, but you had better
make sure that it doesn't overlap with your daughter's recital.
(Or with your plane travel, as recently happened to me,
not taking account of timezones properly.)

It's not simply a question of storing the user's
calendar data on the corporate server: some parts of the user
calendar may want to be kept private from the employer,
such as:
   * job interviews with other companies
   * work for other companies - for the increasingly large 
      fraction of the workforce that are consultants or contractors

More and more, the individual is computer augmented.
The individual needs access to these personal computer
services at the workplace.

--__--__--

_______________________________________________
Design mailing list
Design <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/design

End of Design Digest

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Charles Goodwin | 12 Aug 2003 10:11
Picon

RE: Personal vs Work Computing Services (Calendaring)

> (1) The average PC user has access to 20GB of disk space
> on his PC or laptop - and that's a stat that is a year or
> so old.   At the corporate IT filesystem, he or she typically
> has access to less than a gigabyte.

The average PC is not stable, reliable, nor persistently connected to the
internet.  I agree that _storage_ is an increasingly moot point these days.
But there's more to workable, accessible servers than storage.

This is something the Chandler team might want to push as a service, the
'calendering' equivalent to Hotmail.

- Charlie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

andy.glew | 12 Aug 2003 18:06
Picon
Favicon

RE: Personal vs Work Computing Services (Calendaring)

> The average PC is not stable, reliable, nor persistently 
> connected to the internet.

And the PC is where the user interface is.

So you better be able to deal with
non-persistent connections to the internet.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Oren Sreebny | 12 Aug 2003 19:08

RE: Personal vs Work Computing Services (Calendaring)

given that comcast has been brought to its knees in our region by the
microsoft rpc exploit, i can only say amen :(

- Oren

On Tue, 12 Aug 2003 andy.glew <at> amd.com wrote:

> > The average PC is not stable, reliable, nor persistently
> > connected to the internet.
>
> And the PC is where the user interface is.
>
> So you better be able to deal with
> non-persistent connections to the internet.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

andy.glew | 14 Aug 2003 19:01
Picon
Favicon

RE: Personal vs Work Computing Services (Calendaring)

> My point was you could not have a calender server at home in 
> the current climate, because you could not rely on it being 
> available when you are _away_ from home, which is the whole 
> purpose of the exercise - so you can view your personal 
> calender on your work pc as well as vice versa.

Augmenting my last reply:

(1) I would prefer to have a calendar server on my mobile PC
(tablet, laptop, PDA, or maybe eventually a smartphone), 
since that's more available to me than any other
computing device.  I would want this to be my authoritative
calendar server.

(2) As I said in earlier email, my stationary home server
is connected more reliably than I can connect from home
to work across VPN.

(3) Calendar servers at work for many of us cannot be
considered viable, not just because of connectivity
but because of legal concerns.  E.g. I'm a former 
employee of Intel, and a present employee of AMD,
two companies that are direct competitors.
I am still required to perform work on Intel patent
applications. It should be obvious that I should not
make calendar meetings to discuss Intel patents
visible on my AMD calendar; even the title of such
a meeting is suggestive, let alone any attachments 
to the calendar item. 
    Encryption obvious, but not sufficient.
(E.g. one may imagine encryption that obscures all
but the times busy.  But, if I am taking a day of unpaid
leave to work on Intel stuff, it is probably inappropriate 
for AMD to see that my day may have many small timeblocks
scheduled.)
    (By the way, it is very tiresome to be involved
in this, and I wish the Intel lawyers would stop bothering
me. In one case they repeatedly send me a patent, I tell
them I can't sign it because they are claiming prior art,
and then they repeat.)

(4) Calendar servers at a personal ISP are potentially
interesting, again modulo the fact that I do a *lot* of
my computing (and PIMing) in places where I have no
net.connectivity.  But given the assumption of ubiquitous
network access, possibly interesting. I hope that I live
lonng enough for such ubiquity to be ubiquitous.

But this amplifies my real point: You must not think 
of there being a single calendar server.  You must not
assume that employees' calendars reside on an employer's
computer.  Some may; other employees' calendars may need
to be obtained from outsiide the company.

Possibly, even a single individual's calendar may need 
to be composited from multiple sources.  The employer may
not want to allow confidential information such as meeting
titles and phone numbers and attachments outside the company;
and vice versa.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

andy.glew | 14 Aug 2003 23:33
Picon
Favicon

RE: Personal vs Work Computing Services (Calendaring)

> I'm new to "development by mailing list," so please forgive 
> any etiquette errors I may make.

Sigh.  The net has become much more etiquettish.
One of my best friends won the first "Flame of the Month"
award, and now we consider that a bad thing.

> > (1) I would prefer to have a calendar server on my mobile PC 

> It seems to me this choice should be transparent to the 
> calendar itself. 

Yep.

Key: must be ready to handle disconnected operation.

> Very good points.  I agree wholeheartedly that the user's 
> privacy should be preserved by design.  Do you see any 
> problem with making not just the contents of events 
> encrypted, but also event meta-data?  If the event lists' 
> meta-data was available to only those with proper 
> permissions, that would provide basic security.  If the 
> events themselves were also encrypted, they would not show up 
> on a user's calendar at all without that user having the 
> appropriate credentials.  Ideally, unauthorized users would 
> know nothing about such events, other than a given number of 
> them existed in a list (and then only if they had rights to 
> query the event list).

If they don't show up on the calendar at all,
people can't take them into account for scheduling.

Therefore, time blocks must be visible to all people
who have scheduling writes. But, the blocks may be 
hierarchical:  I may have a whole day blocked out
for work with Company1, with lots of little sub-meetings
with Company1 folk.  Company2 would see the top level
time block, but not the sub-blocks, and no other
information - no meeting titles, names, etc.

Example
    Personal Server
       Tuesday - Company1 block
         9-10 Company1 Lawyer meeting
         10-12 Deposition for Cmpany3 vs. Company1
         1-3 Company1 Manager meeting
       Wednesday - Company2 block
         9-10 Company2 Lawyer meeting
         10-12 Deposition for Company4 v. Company2
         1-3 Company2 Manager meeting        
    Company1 Server
       Tuesday - Company1 block
         9-10 Company1 Lawyer meeting
         10-12 Deposition for Cmpany3 vs. Company1
         1-3 Company1 Manager meeting
       Wednesday - blocked
    Company2 Server
       Tuesday - blocked
       Wednesday - Company2 block
         9-10 Company2 Lawyer meeting
         10-12 Deposition for Company4 v. Company2
         1-3 Company2 Manager meeting        > 

Not only are the sub-blocks of Company1 time not
visible to Company2's calendar server, they just
plain aren't stored there.

Could encryption make this work?  Yes...  but if you
use encryption to store encrypted Company1 data on Company2's
machines
   a) it better be strong
   b) you probably have to have a large amount of padding
      or dummy blocks, so that just the presence of encrypted
      data goes further
   c) most US companies now have a policy that goes 
      "employees storing encrypted data on company machines
      must be prepared to decrypt it at any time.
      to refuse to do so is a dismissible offence".

I see that Charles is British.  I know that most European
countries, e.g. Norway, have laws that provide the presumption
of privacy to individuals at work.  In the US, it is the other 
way around. If you want to keep something private, don't 
store it on your employer's computer system.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design


Gmane