Dear All,
According to the previous discussions and the current implementation of
xeclipse's local storage, I propose the following steps to develop the
new local storage for xeclipse:
1. flat structure of cache or local storage
local_storage
|--wikis ->wiki summary
|--spaces ->space summary
|--pageSummaries ->page summary
|--objectSummaries ->object summary
|--pages -> actual page
|--objects -> actual object
2. cache mechanism
2.1 every time, when user retrieves remote information of
wiki/space/page, store the summary information in the corresponding
folders if it is cached yet.
2.2 every time, a page or an object is opened, cached it to pages/ or
objects/ folder
2.3 maintain an index of last visited objects/pages
3. cache format
I plan to use json to replace the current xml serialization, because
json is more efficient in marshalling and unmarshalling. The libary of
gson will be used to perform the job.
4. index
I am not sure how to implement index for this flat structure. To me,
hashMap might be enough; key is the xeclipse id and value is the actual
object/page/space/etc. I have looked at several popular cache libraries
(e.g., jboss cache, hibernate, EcipseLink, etc.), but it seems to me
that they are over-killed in this case.
Any advice would be highly appreciated.
Best regards
Jun Han
On 06/27/2011 06:36 AM, Eduard Moraru wrote:
> Hi Jun,
>
> On Sun, Jun 26, 2011 at 2:00 AM, Jun Han<[email protected]> wrote:
>
>> Dear All,
>>
>> I have some questions about the LocalDataStorage implementation and Page
>> resources display.
>>
>> 1. The current LocalDataStorage implementation uses xmlrpc model and the
>> cache structure looks like the following:
>> index
>> |-space
>> |-page
>>
>> As the xmlrpc model is being replaced by org.xwiki.eclipse.model package,
>> do we need to modify the local storage as well,
>
> Yes, LocalDataStorage needs to be refactored to use org.xwiki.eclipse.model
> objects.
>
>
>> e.g., adding a folder to store various wikis?
>>
> We definitely need to take into account multiple wikis. Either we add a new
> folder in the existing hierarchy or we have a flat index where the wiki,
> space and page are part of the file name.
> Currently, the index is structured hierarchically but the actual
> pages/objects/etc. have a flat structure.
>
> I see no point in having (1) different locations and (2) different structure
> for index and data. These 2 should be merged into a single hierarchical
> structure inside the 'local_data' folder.
>
> But, since you need to advance quicker on the REST implementation, I propose
> that, for now, you just extend the current structure to include wikis.
>
>
>> I am not very clear about how local storage works. My rough understanding
>> is like this:
>> (1) When user accesses a page, local cache stores it.
>> (2) Whenever user makes a change in the editor, store it in the local cache
>> (3) when user performs a submission, synchronize the content
>>
> Yes, you have all the details in
> https://github.com/xwiki/xwiki-eclipse/blob/master/plugins/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/DataManager.java
>
> Basically, the get methods also store in the local cache (if connected) or
> retrieve from local cache (if offline). Store methods save locally and
> synchronize with the remote wiki (if conencted) or just save locally if
> offline and later on, when the connection is available, synchronize with the
> remote wiki.
>
>
>> 2. I have asked how to display page information before, the suggestion from
>> Eduard is the following:
>> ------ WebHome (PageSummary)
>> -------- Attachments
>> ---------- dog.png
>> ---------- spreadsheet.xls
>> -------- XWiki.XWikiComments
>> ---------- 0 : Administrator ('author' property value)
>> ---------- 1 : Guest
>> ---------- 2 : Administrator
>> -------- XWiki.MyClass
>> ---------- 0 : etc.
>> ---------- 1 : etc.
>>
>> However, I am not sure what else needs to be included? e.g, annotations,
>> versions, history, translations?
>> Once confirmed, I will start working on the page content.
>>
> I`d like to add that annotations should be displayed just like normal XWiki
> objects, same as comments. Also, history(=versions) and translations should
> be kept in a menu.
>
> The only reason why I suggested that we display Attachments in a special way
> is because, internally, they are not handled as XWiki objects and that
> forces us as well to handle them specially in XEclipse. The rest, are just
> XWiki objects.
>
> Thanks,
> Eduard
>
>> Best regards
>>
>> Jun Han
>>
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
