Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 60261 invoked from network); 11 Apr 2007 10:06:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Apr 2007 10:06:45 -0000 Received: (qmail 75920 invoked by uid 500); 11 Apr 2007 10:06:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 75872 invoked by uid 500); 11 Apr 2007 10:06:50 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 75861 invoked by uid 99); 11 Apr 2007 10:06:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2007 03:06:50 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=RCVD_IN_NJABL_PROXY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [193.140.100.220] (HELO uludag.org.tr) (193.140.100.220) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2007 03:06:42 -0700 Received: from [192.168.2.4] (unknown [85.108.97.37]) by uludag.org.tr (Postfix) with ESMTP id 2AF265F385F0 for ; Wed, 11 Apr 2007 13:06:15 +0300 (EEST) Message-ID: <461CB397.2030407@pardus.org.tr> Date: Wed, 11 Apr 2007 13:08:23 +0300 From: =?ISO-8859-9?Q?=22Mehmet_D=2E_Ak=FDn=22?= User-Agent: Mozilla Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [LDAPStudio]LDAP core functions References: <461B88E0.1020106@pardus.org.tr> <461BE730.2020901@apache.org> In-Reply-To: <461BE730.2020901@apache.org> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Stefan Seelmann wrote On 10-04-2007 22:36: > Hi Mehmet, > > >> We are planning to write a management application in which we need to >> manipulate and query data on a LDAP server. Things like user, groups >> computer and software configurations will be in the repository and our >> program will be a graphical user interface to manipulate and query these >> specific data. (Something like Microsoft's Active directory console, but >> ours will be for a Linux distro..) >> >> LDAP Studio provides perfect schema definition and querying >> capabilities. and it allready has lots of boilerplate code like ldif, >> query and schema parsers. What I am asking is, Is it possible to use >> this core functions out of the studio, There are some LDAP Java SDK's >> like OpenLDAP Java SDK, Mozilla's LDAP SDK etc. I am quite confused by >> options here. Would it makes sense writing our schema editor modules as >> Eclipse plugins and deploy them with LDAP Studio , there by having both >> low level access to LDAP and specific management GUI's for our own schema? >> > > First the bad news: It is not possible to use the > ldapstudio-browser-core outside of Eclipse. This is because all the I/O > operations are interacting with the Eclipse Jobs API. > > However if you plan to write your GUI as Eclipse/SWT plugins it would > make sense to use the ldapstudio-browser-core plugins. Because it also > provides a good integration with the Eclispe Job API (which enables a > non-blocking GUI while performing I/O operations). > > On the other hand, sadly, the ldapstudio-browser-core wasn't designed to > be used by other plugins. The API is *NOT* stable and it isn't well > documented yet. We would change some thinks, for example we would > replace the internal schema parser by the shared-ldap schema parser that > is able to handle advanced schema elements like nameForms and > ditContentRules. > > So if you are interested in following Alex' suggestion we could try to > improve the core plugin to be used by other plugins. (Also our Schemas > Editor plugin could use it to edit the schema in the server online) I > will start to describe the architecture of the core plugin, so we could > discuss how to improve it: > http://directory.apache.org/ldapstudio/ldap-studio-architecture.html > > Regards, > Stefan > > > Thanks for all the replies. We are in evaluation phase, and dont have much time to deliver something at least functional on some areas. We are also considering using OpenLDAP SDK and a simple swing (or swt, web?) GUI or maybe something with Python and pyQT. I would like to work with LDAP Studio project on improving things and adding this new functionality, but if I am not mistaken, current state of the code might take some time to be suitable for us. Maybe I should try a simplest plugin that uses mentioned functionality and see if it is feasible. I haven't examined code deeply, but wouldnt it make sense to seperate model code from view a bit further , even taking all of it outside as a shared jar , therefore providing functionality to external third parties and guys like us :) best regards Mehmet D. AKIN Pardus Linux