Etria Lists

Tom Lazar wrote:
> On Sep 19, 2007, at 10:58 AM, Tim Hicks wrote:
> 
>>> Modified:
>>> quills.remoteblogging/trunk/quills/remoteblogging/browser/metaweblogapi.py
>>>
>>> ==============================================================================
>>>
>>> ---
>>> quills.remoteblogging/trunk/quills/remoteblogging/browser/metaweblogapi.py   
>>> (original)
>>> +++
>>> quills.remoteblogging/trunk/quills/remoteblogging/browser/metaweblogapi.py   
>>> Tue Sep 18 21:43:16 2007
>>> @@ -115,14 +115,12 @@
>>>      def getUsersBlogs(self, appkey, username, password):
>>>          """See IMetaWeblogAPI.
>>>          """
>>> -        app = IUIDManager(self.context).getByUID(appkey)
>>> -        return IUserManager(app).getWeblogsForUser(username)
>>> +        return IUserManager(self.context).getWeblogsForUser(username)
>>>
>>>      def getUserInfo(self, appkey, username, password):
>>>          """See IMetaWeblogAPI.
>>>          """
>>> -        app = IUIDManager(self.context).getByUID(appkey)
>>> -        return IUserManager(app).getUserInfo(username)
>>> +        return IUserManager(self.context).getUserInfo(username)
>> Yes, as you suspected in your tracker message, this part of your change
>> caught my eye.  Can you give the rationale for the change?
> 
> sure. the reason was that the getUsersBlogs and getUserInfo both
> attempted to first fetch an object with a UID of appkey.

Yes.

> this uid
> however never existed in any of the cases that i tested.

That's very strange.  I thought that we were, everywhere, returning UIDs
for the appkey, and even instructing (logged-in) users to use a string
that is the UID of the weblog that they are viewing if they want to use
remote blogging.  How was ecto getting hold of the appkey in your
testing?  It sounds like this is where the real bug is.

> as per
> specification of metaweblog API this mechanism is intended to discover
> *all* blogs (of a given user) at a given url.

Yes.  The implementation that I was going for was that, with the appkey
being the UID of a particular weblog, then that weblog is effectively
the 'app', meaning it makes sense for it to only return itself as the
available weblog for the user.

However, that's just a particular implementation specific to Quills (and
specific to an appkey that corresponds to a particular weblog).  The
metaWeblog view could be declared against a plone site root, in which
case it would need to be able to return *all* available weblogs for the
user.

With your change, the flexibility of the metaweblogapi implementation -
which is supposed to be generic, and not quills.app-specific - is lost.
 My suspicion is that your change skirts around a bug, rather than
fixing it.

> actually, i'm not sure, what the previous implementation did. i also
> don't know how the client acquires the 'appkey' that it provides.

That would seem to be the source of the problem.

Are you able to look at this again?


Tim