Re: [PyCS-devel] big cvs commit

[Phillip P. <pp...@my...>]

> Hmm. I think that is not sufficient. Reason: what if people want to remove
> postings? What if they update postings? Should people allways send all
> postings in (that wouldn't be a real option for me - too much postings).
> 
> So how could you decide what to do with the postings in the database? I think
> mirrorPosts should just add/update postings. deleteMirroredPosts should
> get a list of post ids and delete them.

Sorry, I didn't explain clearly.  mirrorPosts _does_ just add/update
posts.  You send it a few posts, and it adds them into the database if
it doesn't have them, or updates them if it does have them.  If you're
seeding the database, you send it 10 posts at a time until you're
done.  You never send all the posts at once :-)

A deletedMirroredPosts call is required, yes.  Perhaps
xmlStorageSystem.deleteMirroredPosts(email, password, posts), with
'posts' being a list of postids to delete.

> PyDS does allow both post updates and post deletes. And then there is the
> problem of categories - posts can be on the homepage or not (as with Radio)
> and can be in categories or not. So people might change posts with regard
> of their homepage/categories and so might move them from homepage to a
> category or back. This would imply changed guids (and therefore changes in
> postings, too).

If a post only lives in one place, you can just call mirrorPosts again
and the GUID and URL will be updated.

If it's possible for a post to have more than one category (i.e. more
than one URL), this would force you to only pass one in.  Do you think
this could be a problem?

Maybe in future we could give the mirroredPosts.posts table a new
field, category[catname:S], and allow search on category...

> So I think we need explicit delete an update support. And maybe we need
> some way to sync - think of people doing strange things with their data
> and don't know what posts actually changed (like some changes in shortcuts
> in PyDS - this would change posts, even though currently this isn't
> upstreamed automatically, this might some day when conditional rerendering
> is in place). Some sync-Call that returns a list of hashes to store in the
> client database might help, so people can say "look, this is the list of
> post hashes I have in my database, tell me which ones you need me to upload
> (again) to get in sync with me".

That's a good idea.  "xmlStorageSystem.getMirroredPostSummary", which
returns a list of dicts, something like:

[{'postid': 'foo',
'hash': md5("|".join(guid + url + title + text))}]

> Oh, and we should return a new flag in the server capabilities to automatically
> enable this search mirror feature.

flCanMirrorPosts <-- always true

and then if the user has sent in some posts, flCanHostSearch should be
true and flSearchUrl should point to /system/search.py?u=0001234 ...
(I might have got those last two key name wrong; substitute with
whatever RCS uses).

Sound OK?

Cheers,
Phil :-)