You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by Stephen Duncan <st...@gmail.com> on 2006/06/23 12:48:31 UTC
Abdera and Feed Thread
I'm not subscribed to the commits list (that's a bit too much for me),
so I'm only seeing the information on this on James' blog:
http://www.snellspace.com/wp/?p=372
Honestly, I'm concerned about this addition. Certainly I think it's a
large enough change, both in raw API terms as well as in scope of the
API, that it deserved discussion on the list first, moreso than many
other things that have been discussed.
Is first-class support of certain extensions the way to go? By
first-class support, I mean addition of custom methods on the core
model objects. I think that's going to be confusing to users who will
assume that the methods are part of the core Atom spec. As more
extensions got this treatment, those interfaces are going to go
bloated, right?
Even if it is the right thing to do, adding methods for extension to
the core interfaces, what's the criteria for choosing which extensions
get supported this way?
Personally, I'd rather see Abdera focus on making using extensions
that are added as separate independent code easy enough to use, that
adding them to the core interfaces doesn't even feel like it makes
sense anymore.
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: Abdera and Feed Thread
Posted by Stephen Duncan <st...@gmail.com>.
Thanks! I haven't looked at the code, but it sounds exactly like what
I was hoping for. I apologize for not realizing this code had been
there the whole time (which clearly invalidated my "dicuss it first"
complaint).
-Stephen
On 6/23/06, James M Snell <ja...@gmail.com> wrote:
> Ok, so I just checked in the change that moves Feed Thread support out
> to an extensions module. Luckily, it's still drop dead easy to use :-)
>
> Entry entry1 = Factory.INSTANCE.newEntry();
> entry1.setId("tag:example.org,2006:/original");
> ...
>
> Entry entry2 = Factory.INSTANCE.newEntry();
> entry2.setId("tag:example.org,2006:/response");
> ThreadHelper.addInReplyTo(entry2, entry1);
>
> // or
>
> InReplyTo inReplyTo = entry.addExtension(ThreadConstants.IN_REPLY_TO);
> inReplyTo.setRef(...);
> ...
>
> - James
>
> Garrett Rooney wrote:
> > On 6/23/06, James M Snell <ja...@gmail.com> wrote:
> >> There are methods on Entry and Factory to support Feed Thread.
> >
> > If there are methods on Entry and Factory related to threading, how
> > would it be possible to separate it out into an extension?
> >
> > -garrett
> >
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: Abdera and Feed Thread
Posted by James M Snell <ja...@gmail.com>.
Ok, so I just checked in the change that moves Feed Thread support out
to an extensions module. Luckily, it's still drop dead easy to use :-)
Entry entry1 = Factory.INSTANCE.newEntry();
entry1.setId("tag:example.org,2006:/original");
...
Entry entry2 = Factory.INSTANCE.newEntry();
entry2.setId("tag:example.org,2006:/response");
ThreadHelper.addInReplyTo(entry2, entry1);
// or
InReplyTo inReplyTo = entry.addExtension(ThreadConstants.IN_REPLY_TO);
inReplyTo.setRef(...);
...
- James
Garrett Rooney wrote:
> On 6/23/06, James M Snell <ja...@gmail.com> wrote:
>> There are methods on Entry and Factory to support Feed Thread.
>
> If there are methods on Entry and Factory related to threading, how
> would it be possible to separate it out into an extension?
>
> -garrett
>
Re: Abdera and Feed Thread
Posted by James M Snell <ja...@gmail.com>.
The methods on Entry and Factory are non-critical and can be removed.
They're there only make it easier to mark an entry as a response to
another entry (e.g. entry.addInReplyTo(anotherEntry)..)
It would take just a bit of refactoring to move them out. Shouldn't
take more than just a few minutes actually.
- James
Garrett Rooney wrote:
> On 6/23/06, James M Snell <ja...@gmail.com> wrote:
>> There are methods on Entry and Factory to support Feed Thread.
>
> If there are methods on Entry and Factory related to threading, how
> would it be possible to separate it out into an extension?
>
> -garrett
>
Re: Abdera and Feed Thread
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/23/06, James M Snell <ja...@gmail.com> wrote:
> There are methods on Entry and Factory to support Feed Thread.
If there are methods on Entry and Factory related to threading, how
would it be possible to separate it out into an extension?
-garrett
Re: Abdera and Feed Thread
Posted by James M Snell <ja...@gmail.com>.
There are methods on Entry and Factory to support Feed Thread.
Elias Torres wrote:
> Stephen,
>
> I'm looking at the source and I only see it in a couple of places. First
> , some constants in Constants.java and then a ThreadHelper in util
> package. It's not that part of the core API, maybe I'm missing something.
> [snip]
Re: Abdera and Feed Thread
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/23/06, Elias Torres <el...@torrez.us> wrote:
> Stephen,
>
> I'm looking at the source and I only see it in a couple of places. First
> , some constants in Constants.java and then a ThreadHelper in util
> package. It's not that part of the core API, maybe I'm missing something.
>
> Maybe it should move out of util and move into .extensions package?
> Maybe the constants should move out of the core Constants.java? I think
> that'd be just fine.
I actually had the same concerns as Stephen, and would feel somewhat
more comfortable if it was an extension. That said, if for some
reason this is difficult to do as an extension, I don't feel that
strongly about it, it just felt a little wrong to have non-core stuff
in the core of abdera.
-garrett
Re: Abdera and Feed Thread
Posted by Elias Torres <el...@torrez.us>.
Stephen,
I'm looking at the source and I only see it in a couple of places. First
, some constants in Constants.java and then a ThreadHelper in util
package. It's not that part of the core API, maybe I'm missing something.
Maybe it should move out of util and move into .extensions package?
Maybe the constants should move out of the core Constants.java? I think
that'd be just fine.
-Elias
Stephen Duncan wrote:
> I'm not subscribed to the commits list (that's a bit too much for me),
> so I'm only seeing the information on this on James' blog:
> http://www.snellspace.com/wp/?p=372
>
> Honestly, I'm concerned about this addition. Certainly I think it's a
> large enough change, both in raw API terms as well as in scope of the
> API, that it deserved discussion on the list first, moreso than many
> other things that have been discussed.
>
> Is first-class support of certain extensions the way to go? By
> first-class support, I mean addition of custom methods on the core
> model objects. I think that's going to be confusing to users who will
> assume that the methods are part of the core Atom spec. As more
> extensions got this treatment, those interfaces are going to go
> bloated, right?
>
> Even if it is the right thing to do, adding methods for extension to
> the core interfaces, what's the criteria for choosing which extensions
> get supported this way?
>
> Personally, I'd rather see Abdera focus on making using extensions
> that are added as separate independent code easy enough to use, that
> adding them to the core interfaces doesn't even feel like it makes
> sense anymore.
>
Re: Abdera and Feed Thread
Posted by James M Snell <ja...@gmail.com>.
As an FYI, the Feed Thread stuff was added before the code came to
Apache. It was part of the initial checkin.
Another point is, given that Feed Thread is now a Proposed Standard,
(the same level of standardization as Atom itself), I personally have no
problems merging it (and any extension that goes through the trouble of
standardization) into the core API. However, it is very easy to
separate out into a separate package.
- James
Stephen Duncan wrote:
> I'm not subscribed to the commits list (that's a bit too much for me),
> so I'm only seeing the information on this on James' blog:
> http://www.snellspace.com/wp/?p=372
>
> Honestly, I'm concerned about this addition. Certainly I think it's a
> large enough change, both in raw API terms as well as in scope of the
> API, that it deserved discussion on the list first, moreso than many
> other things that have been discussed.
>
> Is first-class support of certain extensions the way to go? By
> first-class support, I mean addition of custom methods on the core
> model objects. I think that's going to be confusing to users who will
> assume that the methods are part of the core Atom spec. As more
> extensions got this treatment, those interfaces are going to go
> bloated, right?
>
> Even if it is the right thing to do, adding methods for extension to
> the core interfaces, what's the criteria for choosing which extensions
> get supported this way?
>
> Personally, I'd rather see Abdera focus on making using extensions
> that are added as separate independent code easy enough to use, that
> adding them to the core interfaces doesn't even feel like it makes
> sense anymore.
>