You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(20) |
Nov
(4) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(9) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <m.m...@lo...> - 2008-10-30 13:22:07
|
Hi all, the first version of LogicalDOC Architecture was released and committed on SVN. You can download it from http://downloads.sourceforge.net/logicaldoc/logicaldoc-architecture-3.6.pdf?use_mirror= This is only a first release, but it contains useful informations about the platform, so all developers are invited to download and read this small document. Best Regards --------------------------------------------------------------- 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 |
From: <m.m...@lo...> - 2008-10-30 08:48:38
|
Hi all, the webservice reference was released and committed into SVN repository. You can also download the pdf from http://downloads.sourceforge.net/logicaldoc/logicaldoc-webservice-en.pdf?use_mirror= This document explains the operations exposed by LogicalDOC web services and is a useful reference for integration projects. Regards --------------------------------------------------------------- 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 |
From: <m.m...@lo...> - 2008-10-28 07:39:55
|
Yes you have understood all things, except the fact that we have to use LDAP/Active Directory for authentication only because the authorization will be done using LogicalDOC security objects (users,groups,menus). I propose you an idea, tell me what do you think: * The user authenticate inputs username and password in the LogicalDOC login form * Il the user exists in the DB all things go normally * If the user doesn't exist, the LDAP/ActiveDirectory will be accessed and authentication will be done against LDAP/ActiveDirectory * LogicalDOC creates the user in the DB and assigns to it all the groups specidied by LDAP/ActiveDirectory * From this point all security issues will be handled with LogicalDOC security system This is only an idea, feel free to express your own thoughts and proposals. Even ACEGI is only an idea, ACEGI is well itegrated with Spring and it's pluggable mechanism allows us to integrate various stores such as LDAP and ActiveDirectory. But the use of ACEGI is not a must, you can propose other alternatives. Many Thanks Rajiv Rajiv wrote: > Sure Marco, I will start looking at the existing security code right away. > As far as ACEGI is concerned, I have not used it in any project but > have worked with other java libraries for LDAP binding/communication. > However, I will go through ACEGI docs once to get an idea. > > Now, if I understand the requirements right, as of now DB holds the > user, group and permission info and going forward, this info would be > populated in a LDAP server. Everytime a user logs in to the > application he will have to be authenticated and all his actions will > have to be authorised using the LDAP server. The authorisation is done > at the menu level so certain users (belonging to a group) have access > to some menu items and not to other groups menu items. > > As for the LDAP server to be used, I have used Sun Java Directory > Servers in a few projects and have found it to be good (besides being > free :-). Its easy to setup and configure on windows/unix platforms > and has pretty good documentation too. Besides, the LDAP server > integration with the application can be done through JNDI so ideally > any LDAP server can be used. > > Let me know if my understanding of the requirements is right. > > _Rajiv > > PS - will keep you posted on the progress. > --------------------------------------------------------------- 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 |
From: <m.m...@lo...> - 2008-10-27 07:37:03
|
Rajiv wrote: > Alessandro/Marco, > > I would be glad to be of help on any of the points you had mentioned. > If point 1 is an immediate concern, I can take it up as well. > > Mail me the requirements/design (if there is a design doc already in > place) and the timelines. > Also, let me know of the development process that is being followed > for this project. > > _Rajiv > Hi Rajiv, we do not have a formal document to send you, at the moment we are producing documentation regarding installation and platform architecture. But we have a very pressing need: LogicalDOC must be able to interface with external LDAP and Active Directory. Our primary goal is to get users and groups from LDAP and Active Directory for authentication. In your opinion is it possible to use ACEGI? And if not is there a Java library that can be integrated into LogicalDOC? In LogicalDOC security goes as follows: * Each User can be member of Groups * Permissions can be assigned to Groups in regards of a Menu * The Menu is the central security concept: folders are a particular type of menu So these are the tasks for you(if you want): 1. Take a look on how security is implemented in LogicalDOC 2. Make a research to find the right tools to be used for LDAP/ActiveDirectory and tell us your results 3. Exchange with us your idea of integration into LogicalDOC of an external authentication mechanism 4. Implement the solution int the core module We wish to have the integration with an external authentication system ready for the end of november. We can exchange ideas by e-mail, using the developer's list or using the wiki. Let's go Rajiv, we count on you! --------------------------------------------------------------- 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 |
From: Marco M. - L. O. s. <m.m...@lo...> - 2008-10-26 08:39:57
|
Hi there, the new module logicaldoc-testbench was imported into SVN. This module is intended to contain all tools and resources able to create a test archive for logicaldoc. The first goal is to create real huge document archives to test LogicalDOC performances. Best Regards --------------------------------------------------------------- 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 |
From: Alessandro G. <a.g...@lo...> - 2008-10-25 10:29:20
|
The LogicalDOC project is pleased to announce the availability of our new Issue Tracker service. This system will allow us to manage the roadmap of the project, the historical issues and easily generate changelogs of any release of the software. It is already available for reporting at http://issues.logicaldoc.com Best regards Alessandro |
From: <m.m...@lo...> - 2008-10-22 13:10:02
|
Hi there, we have added the new development module logicaldoc-webdav as a place holder for WebDAV issues. This module will implement a LogicalDOC plug-in that will add WebDAV capabilities to the platform. This plugin is part of the core distribution. For Gustav We have already added the attribute pathExtended on Menu (column ld_pathextended) and The MenuDAO.store() method takes care to update ld_menu table. Menu and MenuDAO are part of the core API so they are placed into logicaldoc-core module. If you need new finder methods in MenuDAO or other DAOs feel free to ask us o to update the source code, but remember to develop also automated tests for each new finder method (see HibernateMenuDAOTest) Best Regards --------------------------------------------------------------- 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 |
From: <m.m...@lo...> - 2008-10-22 06:58:37
|
sw...@kr... ha scritto: > Good Morning, > > all right, the approach for WebDAV should now clearly set(by ld_folderpath). > > First WebDAV Implementations would be: > > + Read/Write > + Windows Access > > - No WebDAV Web Access (?) > Our primarily goal is to give access as a windows disk, but of sure we can also develop a web access it we agree it is compliant with the product's philosophy: 'Logic and Simplicity' > Second Step: > + Permission Handling > + Locked Items-Handling > > My mention about integration into logicalDOC is, that this should be a core feature of logicalDOC. Its a part of the main access-layer for managing data. > > Best Reagards > Yes Gustav, this will be a core feature and do not worry because this module will have access to all data layers. I prefer to develop WbDAV into an appropriate module for ease of development but if WebDAV needs modifications in the core DAOs we will update whatever it will be needed. Please, be patient in this fase, since we don't have documentation(we will publish it ASAP), I try to help you and guide you for now. So, today i will add the new property in the core business object Menu and i will produce automated test to check the correct handling of ls_menu table, after this we will be ready to start WebDAV development. Let's go --------------------------------------------------------------- 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 |
From: <sw...@kr...> - 2008-10-22 05:26:43
|
Good Morning, all right, the approach for WebDAV should now clearly set(by ld_folderpath). First WebDAV Implementations would be: + Read/Write + Windows Access - No WebDAV Web Access (?) Second Step: + Permission Handling + Locked Items-Handling My mention about integration into logicalDOC is, that this should be a core feature of logicalDOC. Its a part of the main access-layer for managing data. Best Reagards |
From: Marco M. - L. O. s. <m.m...@lo...> - 2008-10-21 18:44:44
|
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 |
From: <m.m...@lo...> - 2008-10-21 13:10:39
|
m.m...@lo... ha scritto: > First of all, it's a pleasure to speak about issues like this, well >> Hi there, >> >> surely i could agree with you in that case that we implement this >> approach by creating a "folder-table". Reconsiderd again, i mention >> we should keep an eye(or better a bunch of eyes) on this behaviour. >> There are much more implications we dont seeing yet. If we have an >> amount of 50 Folders, of course, changing is really fast possible, >> but it depents on transaction level if other peoble are currently on >> the table. Highly frequency gets worse. Therefore we should consider >> following questions: >> >> First: How often will be a folder moved? > By now in LogicalDOC, folders cannot be moved: the user can move > documents only. >> Second: How many Folders and Subfolders exists? > this is unpredictable, i suggest to consider an amount of 2% against > the total amount of documents (2 folders each 100 documents) >> Third: How often is a folder renamed? > In my opinion the folder rename is no frequent, we could estimate one > write in ld_menu each 1000 writes into ld_document. But i think that > one the archive is created it is difficult that a folder changes name. > It is more frequent that new folders are created. >> Fourth: What measures more of the first three points? > I thing that the point is the number of folders that basically is the > number of records in table ls_menu >> >> My mention is that its more possible that a folder must be moved as >> renamed. The payload is unequally higher on the first point if we >> having a folder-table. The amount of payload is defined by the second >> point. The more subfolders exists the longer must be a transaction >> avoid changes/reads(Transaction Level) from other processes. >> Furthermore we have to lookup every WebDAV Request on ever Datarow >> for getting the right one. 250 Folders a 100 KB are 2,5 megabyte that >> have to be each call loaded from hard-drive to the db cache >> (theoretically). In real cache has got in most cases enough size. > 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? >> >> In fact, using that way by using an index on foldersname can be >> usefully as long as we have enough distinguish folders. Index >> speedups, i guess. The really problem on using indices is only then, >> if we have a highly frequency rename party on the system. This >> imagination is rather funny. But if we have such case, index is >> changed and has to be rebuild for synchronizing. But its no really >> big deal for doing this in nightly hours. > Even in the case of DB table, we can maintain it by using a scheduled > job(but i think it is not necessary, we can update it when the user > changes a folder name). >> >> But you asked me for my proposal. >> >> My expierience with thousends of documents is not really god-like at >> all ;-) I agree with you as long as we doing testcases with >> auto-generated folders in an appropriating size at tje end of the >> implementation. >> >> Best Regards > Also we have to face another issue: read permissions. We have to list > only those folders the user can see, but these permissions are stored > int the DB, so the DB solution it is more simple to retrieve only > accessible paths by using SQL join. > > Tell me Gustav, explain me more details about your idea to use the > lucene index and why do you thing this solution is better than the > database one. > I think we can discuss about this issue and find the right solution in > order to start the module development. > > PS > Let me say some development lines that we have to follow, because i > think you can understand me: > > 1. First of all things must run, than they can be beautiful. If a > beautiful feature doesn't run on a large population of > documents, it is dropped > 2. Performances are the key element of this software, we would be > able to give a search respose time of 4 seconds on a polulation > of 1 million documents > 3. The program must be as simple as possible to the end user, it > can be a hell for developers(i hope not so hot) but it MUST be > simple for the end user > > As you can see, we are implementing very deep changes in the data > model in order to maximize performances. > > I appreciate your considerations about performances. My compliments > Gustav! > > --------------------------------------------------------------- > 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 -- --------------------------------------------------------------- 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 |
From: <m.m...@lo...> - 2008-10-21 08:42:20
|
> Hi there, > > i´m in trouble with my mind and want the same of you as from now :) > My topic belongs to WebDAV-Performance access where i currently work on. > > Access via WebDAV has one particular difference when we comparing dirctly with logicalDOC. By web we getting a much more straight forward path to a folder structure (and his content) using a unique number. Here its ld_menu.ld_id. The consequence is, that we can fairly fast accessing a appropriate folder by this approach. Indexing is adequate for use. > > WebDAV has no such feasability as we have no unqique id or something else for using a efficient index-access. An easy example: > > / (Root) > /My Images > /Documents > -|/... > -|/Bills/Something other/ > -|/... > > If we want going into the folder Bills(because we have something for pay and dont know the right folder at all) by starting over the root, we have to asking the DB six times for getting the right folder: > > / > /Documents > /Documents/Bills > > So we have a much more semantically access as an technically (as with IDs) procedure. The Problem is now, that we riding into a performance-farce when we looking at a use-case of 60.000 Documents anf folders or much more. > > What solutions exists? > > 1. No Changes > 2. Indexing FolderNames > 3. FolderTable > > 1) No Changes are good for us. Because we have to change nothing and can drinking a lot of whisky at the evening for relaxing and so on... But costumers/users getting rather angry when they have thousends > of documents to mange. Taking again the example above, we have to take 6(N^2 where N is the number of folders to the target-folder) times a full table scan on the ld_menu and on index-access. We need this count as we have getting at first the right folder (e.g. /Documents) and then the documents within the folder. > > 2) Indexing the name of the folder(ld_menu) attribute. Its on way, but ever DML on foldernames will be driving into a index-change which can cause transactional errors or performance-issues. I say, it can but its one way we can go without big changes and see in the future (or by costumer reports) whether this way turns into a much more inconvenienced situation. > > 3) Third possibility is to create a new table that holds ever folder path - and i mean an absolutly path - in the table. For Instance: > > ______PATH_____________________________________ID____ > /My Images ....................................1 > /My Images/Image Album I ......................2 > /My Images/Image Album I/thumbnails ...........3 > /Documents ....................................4 > > Every document is referencing to one ID. By WebDAV(and the usage is only for webdav or CIFS) we can passing the current path ino a sql-query and the db must take one FTS. The problems here are very wide-spreaded. For example, if we want to changing a folder that is positioned upon the middle (Image Album I) we have changing ID 2 and 3 for stay clear in the database. > > > Therefore i suggest the second point. > > Best Regards > Hi Gustav, many thanks for your very interesting considerations. First of all LogicalDOC must be able to handle up to 1 million documents(this is the reason for current refactorings) so we have to find a solution for WebDAV. Currently indexes stores document metadata and for each entry we have an attribute 'path' that saves the document's path(in term of folder ids), e.g.: /5/28/45/31 The index is kept updated each time a document changes. We are able to add another field let's say 'folders' populated with folder path like '/My Images/Image Album I/thumbnails' But each time we change a folder we have to update the index that may contain 1 million documents. This operation can be very problematic. I thik that the best solution is the third one and implemented as follows: 1. Create a table ld_pathid(ld_path,ld_folderId) 2. The MenuDAO updates this table each time a folder changes In this way the table ld_pathid is always updated and ready to use, the update operation is no so complex and above all changes in dolfer names are not so frequent as changes in documents. What do you think? --------------------------------------------------------------- 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 |
From: <sw...@kr...> - 2008-10-19 19:16:30
|
Hi there, i´m in trouble with my mind and want the same of you as from now :) My topic belongs to WebDAV-Performance access where i currently work on. Access via WebDAV has one particular difference when we comparing dirctly with logicalDOC. By web we getting a much more straight forward path to a folder structure (and his content) using a unique number. Here its ld_menu.ld_id. The consequence is, that we can fairly fast accessing a appropriate folder by this approach. Indexing is adequate for use. WebDAV has no such feasability as we have no unqique id or something else for using a efficient index-access. An easy example: / (Root) /My Images /Documents -|/... -|/Bills/Something other/ -|/... If we want going into the folder Bills(because we have something for pay and dont know the right folder at all) by starting over the root, we have to asking the DB six times for getting the right folder: / /Documents /Documents/Bills So we have a much more semantically access as an technically (as with IDs) procedure. The Problem is now, that we riding into a performance-farce when we looking at a use-case of 60.000 Documents anf folders or much more. What solutions exists? 1. No Changes 2. Indexing FolderNames 3. FolderTable 1) No Changes are good for us. Because we have to change nothing and can drinking a lot of whisky at the evening for relaxing and so on... But costumers/users getting rather angry when they have thousends of documents to mange. Taking again the example above, we have to take 6(N^2 where N is the number of folders to the target-folder) times a full table scan on the ld_menu and on index-access. We need this count as we have getting at first the right folder (e.g. /Documents) and then the documents within the folder. 2) Indexing the name of the folder(ld_menu) attribute. Its on way, but ever DML on foldernames will be driving into a index-change which can cause transactional errors or performance-issues. I say, it can but its one way we can go without big changes and see in the future (or by costumer reports) whether this way turns into a much more inconvenienced situation. 3) Third possibility is to create a new table that holds ever folder path - and i mean an absolutly path - in the table. For Instance: ______PATH_____________________________________ID____ /My Images ....................................1 /My Images/Image Album I ......................2 /My Images/Image Album I/thumbnails ...........3 /Documents ....................................4 Every document is referencing to one ID. By WebDAV(and the usage is only for webdav or CIFS) we can passing the current path ino a sql-query and the db must take one FTS. The problems here are very wide-spreaded. For example, if we want to changing a folder that is positioned upon the middle (Image Album I) we have changing ID 2 and 3 for stay clear in the database. Therefore i suggest the second point. Best Regards |
From: <sw...@kr...> - 2008-10-19 09:05:02
|
Do closely comprehending this failure, take a look at a newly (untouched but already installed) dms version 3.6 (windows, default db). Afterwards upload two files and lock(by checkout) one of them. Now when the one unlocked file will be deleted the locked item cascades unexecpected. |
From: Alessandro G. <a.g...@lo...> - 2008-10-15 16:43:07
|
Hi Gustav, I agree with you. To tell the truth I did not know that Jackrabbit api include the code for a WebDav server, but actually after your report I was able to verify their presence. So you can proceed with Jackrabbit, i support your choice. Best regards A.Gasparini * * |
From: <m.m...@lo...> - 2008-10-15 12:26:35
|
Hi to all, we are deeply modifying the core API and DB schema and we need to make service commit into the trunk, so don't worry if something doesn't work properly in the application in the next days. Our aim is to make LogicalDOC able to handle several hundreds of thousands of documents. So, please, be patient. Stay tuned --------------------------------------------------------------- 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 |
From: <sw...@kr...> - 2008-10-13 22:32:40
|
Hi there, after visiting http://jakarta.apache.org/slide/ a "deprecated" project should not be integrated. My mention is now, to use a more sophisticated library such as jackrabbit. Currently i´ve spend some hours to review the code. I would suggest to use those libraries for implementing. Other lightwighter libraries are welcome as long as they supper basic WebDav features. In the mean time i think i should going through this bunch of code lines trying to make up a prototype. Best Regards |