[RPS] get_persons_entries Questions Raised

Daniel Nugent nugend at gmail.com
Fri Jul 1 20:40:41 EDT 2005


Okay, I'll take a crack at one or two of the unimplemented functions
over the weekend.  Not sure how I'd be able to patch it back though
since I'm unfamiliar with CVS (and learning SVN right now).

I've got an idea for a user story I'll write up too.

On 7/1/05, Sean Carley <seanacarley at gmail.com> wrote:
> On 7/1/05, pat eyler <pat.eyler at gmail.com> wrote:
> > On 7/1/05, Daniel Nugent <nugend at gmail.com> wrote:
> > > It sort of seems to me (having really gotten around to looking at the
> > > r43 code and the 43 Things API doc) that the Results object should be
> > > sort of an intermediary array that provides dynamic access to the 43
> > > Things object pagination.  The (possibly) tricky part might be
> > > figuring out how to make this dynamic array fill itself with the
> > > appropriate object type depending on the API responses.  Of course, if
> > > we're only creating these arrays from within methods we call, that's a
> > > lot more trivial.
> > >
> > > As for the name, I *think* R43Result is more Ruby-like since it
> > > follows the Camel Case for Classes rule.  It's just that the whole
> > > first 4 letters being in caps is a little weird.
> >
> > It *is* wierd.  The API refers to the blob as a feed, but I don't tlike the
> > terminalogy because it feels too much like atom/rss.
> >
> 
> I don't like the name feed either.  It does not describe what is being
> done.  I like the name R43result, but I think it would be frequently
> mistyped because it is not true camel case.
> 
> > >
> > > I'd also like to make a suggestion about method and class
> > > organization: It might be a good idea to add aliases to the different
> > > objects for some of the API methods that are closely tied to them.
> > > For example, it would seem natural to be able to do
> > >
> > > foo = Person.new(id_that_we_know)
> > > foo.get_entries
> >
> > I think this makes sense, but I'd like to get the structure and
> > initial methods done first.
> >
> 
> I really like the idea of aliases that match the web service but I
> agree with Pat; it might not be time to add those aliases yet.
> 
> > >
> > > If it's alright, I'm going to take a crack at building that dynamic
> > > array class this weekend unless there's another area you guys would
> > > like me to put a little work into.
> > >
> >
> > How comfortable do you feel working with the code?  If you're
> > comfortable really playing with things, You might want to try working
> > on a couple of the unimplemented methods so that we can get a better
> > feel for how we should extract the feed/result object.
> >
> > I think trying to build too much more on the actual feed/result won't
> > do too much good until we sort it out.
> >
> 
> I agree 100% with Pat on this.  I think every unimplemented method
> will return a feed as the root XML node.  We need a better idea of
> where we are going before we add complex features that might not be
> needed.
> 
> I think we need to take a step back from the code and talk about what
> we want to be able to do with the API.  In the interest of building
> the simplest thing that could possibly work, we need to have some idea
> what we want to achieve.  This might be a good time to develop some
> stories.  If you have an example of something you would like to do
> with r43, please write it up (maybe on the Viki) and let us know on
> the list.  Having concrete achievable goals will help us determine how
> heavy duty r43 should be.
> 
> Sean
> 
> _______________________________________________
> Therps-discuss mailing list
> Therps-discuss at rubyforge.org
> http://rubyforge.org/mailman/listinfo/therps-discuss
> 


-- 
-Dan Nugent



More information about the Therps-discuss mailing list