On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote:

> Vincent Massol wrote:
>> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
>>
>>> Hi devs,
>>>
>>> As it has been already mentioned a couple of times, I strongly  
>>> believe
>>> that XWiki Watch should be accessible in a sandbox on xwiki.org, for
>>> everyone to try it out and explore its features and for us to get an
>>> open real-life test of it.
>>> There is a document dedicated to the issues that might prevent  
>>> this at
>>> http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg ,
>>> please fill it in with any opinions you have!
>>>
>>> Here's my +1 for having an installation of XWatch publicly available
>>> on
>>> xwiki.org, WDYT?
>>
>> Sure, we've already discussed it as I wanted to install it but
>> discovered it wasn't possible at the time. I wouldn't call it a
>> sandbox as I think it could be used for real and contain feeds  
>> related
>> to xwiki and anything relevant.
>>
>> Here are some issues I can think of:
>> 1) Allow unregistered users to view and use the reader
>
> Since Watch is implemented using the XWiki documents & objects  
> model, user
> rights follow the same model as all XWiki. Guest users use the  
> rights we give
> them: for viewing / navigating through the reader, view right is  
> enough, whereas
> any edit (add feed, tag/flag/trash/mark as read articles) requires  
> edit rights.
> Unless there is a problem with giving edit rights to guests, I don't  
> see exactly
> what is the issue with having guests use the reader.

Yes we definitely shouldn't give edit rights to guests. This leads to  
spamming. We need people to be registered for getting edit rights.

But if users can use the reader with only view rights then it's good.  
AFAIR it wasn't working before.

>> 2) Provide ability to undo changes done by users (the revert feature
>> of all wikis). This is especially important in a public instance: it
>> needs to be easier to revert an error than it is to create one!
>
> As mentioned earlier, all Watch data is stored in xwiki documents &  
> objects, so
> reverting is as easy as it can be in any other instance of xwiki.
>
> Now, there is a problem with what we understand by reverting changes  
> in a "feed
> reader". The first example that comes into my mind is when a user  
> adds a feed
> source, say unwanted. Since the feed articles fetched from that are  
> stored in
> xwiki documents, revert (wiki-way) would mean deleting the feed, but  
> that would
> not trigger deleting all fetched articles. While from a feed reader  
> point of
> view, reverting this change would probably mean deleting all fetched  
> articles
> too. For this particular example this is not a problem because  
> deleting a feed
> with all fetched articles is implemented in watch reader interface,  
> but there is
> a general problem of actions and concepts interpretation in Watch:  
> seeing it as
> a wiki vs. seeing it as a feed reader.

We just need to check use case by use case if we have a way to revert  
changes:
* If a user adds an unwanted feed, we can remove it with the delete  
feed button so that's ok
* if a user deletes a feed, how can we restore it?
* if a user creates a spammy comment or tag how can we remove them?
* can a user remove a tag or comment? (probably not or maybe only his  
own tags/comments)
* same questions for the trash and starring.

Ah another point:

4) We need a RSS feeds of all actions that happen in the reader, like  
"adding a new feed", "deleting a feed", "commenting", "flagging", etc  
so that it's possible to follow what's happening and revert if need be.

>> 3) Good performances
>
> Depending on the type of database used and the database setup, XWiki  
> Watch can
> get a little heavy for (arguable) large database sizes (~10000 fetched
> articles), but I think using it on xwiki.org would help better  
> estimating these
> type of problems.

Yes.

Thanks
-Vincent

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to