Re: [Logicaldoc-devel] [Fwd: [WebDAV]Performance that Matters]

[Marco M. - L. O. s. <m.m...@lo...>]

sw...@kr... ha scritto:
> Well, i dont meant the Lucene Index.  When my message came over to you 
> as this can be a potencialy solution, i must renewing my point of view.
>
> Really i´d never would using lucene for such a kind of thing. Becasuse 
> i never have enough knowledge about the Lucene Index and how well the 
> index can handle such issues. My solution is driven by native db 
> access, respective hibernate. So "my implementation" prefered the 
> case, that we have only one folder table for storing ALL paths 
> (absolutally) within. Every path has one ID which will be referenced 
> by every document(N:1 Relationship). That is the point, that you have 
> propesed the last posting, i mention.
>
> When you say, that no rename operation can be performed on folders, 
> the folder-table is a quite appropriate solution, i guess. I make an 
> excerpt from your mail:
>
> <--
> Yes Gustav, but if we store the full path in the index(each entry has 
> a 'folderPath' field), we will have this 100KB multiplied by the 
> number of documents, let's say 60.000 docs and a total amount of more 
> than 5.800MB. Or do you mean we have to create and handle a new index 
> only for folders? But in this case what's better than the DB 
> implementation?
> -->
>
> I think this missapprehension has been resolved above. Therefore, that 
> we referencing from one document on an absolute path, performance 
> should be very well.
So Gustav we agree to the DB solution?  I think that we agree on this 
solution:

    * We add a new column ld_folderpath into table ld_menu(folders are a
      particular type of menu), containing the absolute path using
      folder names
    * The MenuDAO takes care to handle the correct population of this
      field automatically on each save
    * The WebDAV module will use this field for hits elaborations

Is this right? Ca we proceed in this way
> Performance is an important point, choosing the right software-product 
> for such a business-case.
> Your "policy" is therefore more as a "must" as a "should". I would 
> suggest a more deeper look onto the database, especially the 
> physically design for gaining maximum performance. Datablock-Sizes, 
> Storage-Options as well as globalized parameters - for example - could 
> leading into a performance-farce. Perhaps, you and your team still 
> knowing such things, i mention ;-)
>
> Can you explain me, how your integration-process works, especially for 
> WebDAV? You sad that i have to create a submodule, isnt it so?
>
Yes, LogicalDOC has a powerful plugin-system(we have integrated JPF) but 
we don't have documentation. We will produce a Plugin's Manual ASAP but 
in the meanwhile you can take a look to the logicaldoc-webservice module 
that realizes a LogicalDOC's plugin for WebServices.

So i propose you to work together folowing these guedelines:

   1. I prepare the module skeleton for you
   2. You put your code into this module, than i modify it in order to
      correctly integrate your work into the platform
   3. You learn module development by doing

Please excuse me for the lack of documentation, but we are working hard 
to produce good documentation. Personally i think that the lack of 
documentation is an handicap for the project and reduce the developer's 
community. But i say that the first step is to face problems.

So if you agree, i can start with the module creation, but we have to 
decide if this module will be in the core distribution(logicaldoc/) or 
it will be an optional plug-in(modules/).
In my opinion we can place it in the core distribution, after all it is 
a great feature and it can be a distinctive issure of LogicalDOC.
Our aim about WebDAV is to allow the windows user to see LogicalDOC 
archive as a logical unit(like an USB disk)

So Gustav, give me your opinion about this plan

---------------------------------------------------------------
ing. Marco Meschieri
e-mail: m.m...@lo... <mailto:m.m...@lo...>
---------------------------------------------------------------
Logical Objects snc
Via Bonasi, 2/A 41012 Carpi (MO) Italy
Tel./Fax. 059 688969
web: http://www.logicalobjects.it


-- 
AVVERTENZE AI SENSI DEL DLGS 196/2003:
Le informazioni contenute in questo messaggio di posta elettronica e/o 
nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il 
loro utilizzo e' consentito esclusivamente al destinatario del 
messaggio, per le finalita' inidcate nel messaggio stesso. Qualora 
riceveste questo messaggio senza esserne il destinatario Vi preghiamo 
cortesemente di darcene notizia via e-mail e di procedere alla 
distruzione del messaggio stesso, cancellando dal vostro sistema; 
costituisce comportamento contrario ai principi dettati dal Dlgs196/2003 
il trattenere il messaggio stesso, divulgandolo anche in parte, 
distribuirlo ad altri soggetti,copiarlo, od utilizzarlo per 
finalita'diverse. Titolare del trattamento e' Logical Objects SNC Via 
Bonasi 2/A 41012 CARPI (MO) Tel. 059/688969 Fax 059/688969

This e-mail and any file transmitted with it is intended only for the 
person or entity to which is addressed and may contain information that 
is privileged, confidential or otherwise protected from disclosure. 
Copying, dissemination or use of this e-mail or the information herein 
by anyone other than the intended recipient is prohibited. If you have 
received this e-mail by mistake, please notify us immediately by 
telephone or fax. Proprietor of treatment is Logical Objects SNC Via 
Bonasi 2/A 41012 CARPI (MO) Tel. 059/688969 Fax 059/688969