[GSoC 2009] Apache is officially participating in Google Summer of Code 2009

[Bertrand Delacretaz <bd...@apache.org>]

---------- Forwarded message ----------
From: Luciano Resende <lr...@apache.org>
Date: Thu, Mar 19, 2009 at 10:52 PM
Subject: [GSoC 2009] Apache is officially participating in Google
Summer of Code 2009

It's now official, Google has announced that The Apache Software
Foundation was selected as one of the participating organization in
the GSoC 2009 program. This is an excellent opportunity for Apache, as
it allows projects to build/increase its community, it also help
students to learn about open source, about Apache Software Foundation
and how to do things the "Apache Way".

Please start advertising the program and discussing project ideas with
your project community. Then add your project ideas to the ASF GSoC
2009 Official Project Ideas page [1], as this is going to be the most
visible place for students. Per GSoC 2009 timeline, Students should
officially start applying for these ideas on March 23.

ASF Members and committers can volunteer to be mentors in the GSoC
2009 program (see [2] for more details about being a mentor). We
invite all mentors and GSoC interested parties to subscribe to the
code-awards@a.o mailing list [3] to coordinate work between mentors,
ask questions and get updates related to GSoC 2009 program.

Please, feel free to forward this announce to any appropriate dev@ or
users@ lists so your larger community can hear about the GSoC 2009
program.

[1] http://wiki.apache.org/general/SummerOfCode2009
[2] http://wiki.apache.org/general/SummerOfCodeMentor
[3] mailto:code-awards-subscribe@apache.org


--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Other twitter functionality to implement

[David Pollak <fe...@gmail.com>]

On Wed, Mar 25, 2009 at 7:56 AM, Hirsch, Richard <richard.hirsch@siemens.com
> wrote:

> Why couldn't you just have a "deleted" attribute in the message object. Of
> course, then you have to define what happens when a deleted message is
> present in a conversation. Of course, you might have consider performance
> problems.


Because a deleted attribute would mean mutating the message to add the
attribute.


>
>
> D.
>
> ________________________________
>
> Von: David Pollak [mailto:feeder.of.the.bears@gmail.com]
> Gesendet: Mo 23.03.2009 16:42
> An: esme-dev@incubator.apache.org
> Betreff: Re: Other twitter functionality to implement
>
>
>
> On Mon, Mar 23, 2009 at 2:34 AM, Hirsch, Richard <
> richard.hirsch@siemens.com
> > wrote:
>
> > I was exploring the Twitter REST API and was comparing to what we
> > currently support. Although there is some functionality (favorites,
> > block, etc.), there are still some functionality that is open.
> >
> > What about supporting the deletion of messages?
> >
> > * statuses/destroy
> > Destroys the status specified by the required ID parameter.  The
> > authenticating user must be the author of the specified status.
> >
> > I know this currently isn't possible in ESME but I think it is a
> > functionality that is useful. Of course, the inclusion of pools would
> > influence the future implementation (think of pools in which messages
> > can't be deleted based on compliance reasons) but until we have
> > developed pools, the deletion of messages would still be useful.
> >
> > Added a Jira item for this:
> > https://issues.apache.org/jira/browse/ESME-51
> >
> > Thoughts?
>
>
> It makes life very difficult.  I am an anti-fan of mutable messages.  But
> there may be a way around it.  Rather than deleting a message, have a
> separate table of non-displayed messages and the messages in that table are
> used as a filter for the messages in a mailbox.
>
>
> >
> >
> > D.
> >
> >
>
>
> --
> Lift, the simply functional web framework http://liftweb.net <
> http://liftweb.net/>
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
>
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

AW: Other twitter functionality to implement

["Hirsch, Richard" <ri...@siemens.com>]

Why couldn't you just have a "deleted" attribute in the message object. Of course, then you have to define what happens when a deleted message is present in a conversation. Of course, you might have consider performance problems.
 
D. 

________________________________

Von: David Pollak [mailto:feeder.of.the.bears@gmail.com]
Gesendet: Mo 23.03.2009 16:42
An: esme-dev@incubator.apache.org
Betreff: Re: Other twitter functionality to implement



On Mon, Mar 23, 2009 at 2:34 AM, Hirsch, Richard <richard.hirsch@siemens.com
> wrote:

> I was exploring the Twitter REST API and was comparing to what we
> currently support. Although there is some functionality (favorites,
> block, etc.), there are still some functionality that is open.
>
> What about supporting the deletion of messages?
>
> * statuses/destroy
> Destroys the status specified by the required ID parameter.  The
> authenticating user must be the author of the specified status.
>
> I know this currently isn't possible in ESME but I think it is a
> functionality that is useful. Of course, the inclusion of pools would
> influence the future implementation (think of pools in which messages
> can't be deleted based on compliance reasons) but until we have
> developed pools, the deletion of messages would still be useful.
>
> Added a Jira item for this:
> https://issues.apache.org/jira/browse/ESME-51
>
> Thoughts?


It makes life very difficult.  I am an anti-fan of mutable messages.  But
there may be a way around it.  Rather than deleting a message, have a
separate table of non-displayed messages and the messages in that table are
used as a filter for the messages in a mailbox.


>
>
> D.
>
>


--
Lift, the simply functional web framework http://liftweb.net <http://liftweb.net/> 
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Re: Other twitter functionality to implement

[David Pollak <fe...@gmail.com>]

On Mon, Mar 23, 2009 at 2:34 AM, Hirsch, Richard <richard.hirsch@siemens.com
> wrote:

> I was exploring the Twitter REST API and was comparing to what we
> currently support. Although there is some functionality (favorites,
> block, etc.), there are still some functionality that is open.
>
> What about supporting the deletion of messages?
>
> * statuses/destroy
> Destroys the status specified by the required ID parameter.  The
> authenticating user must be the author of the specified status.
>
> I know this currently isn't possible in ESME but I think it is a
> functionality that is useful. Of course, the inclusion of pools would
> influence the future implementation (think of pools in which messages
> can't be deleted based on compliance reasons) but until we have
> developed pools, the deletion of messages would still be useful.
>
> Added a Jira item for this:
> https://issues.apache.org/jira/browse/ESME-51
>
> Thoughts?


It makes life very difficult.  I am an anti-fan of mutable messages.  But
there may be a way around it.  Rather than deleting a message, have a
separate table of non-displayed messages and the messages in that table are
used as a filter for the messages in a mailbox.


>
>
> D.
>
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Other twitter functionality to implement

["Hirsch, Richard" <ri...@siemens.com>]

I was exploring the Twitter REST API and was comparing to what we
currently support. Although there is some functionality (favorites,
block, etc.), there are still some functionality that is open. 

What about supporting the deletion of messages?

* statuses/destroy
Destroys the status specified by the required ID parameter.  The
authenticating user must be the author of the specified status.

I know this currently isn't possible in ESME but I think it is a
functionality that is useful. Of course, the inclusion of pools would
influence the future implementation (think of pools in which messages
can't be deleted based on compliance reasons) but until we have
developed pools, the deletion of messages would still be useful. 

Added a Jira item for this:
https://issues.apache.org/jira/browse/ESME-51

Thoughts?

D.