Re: JSON license

2010-07-14 Thread Grant Ingersoll
These questions should be asked on legal-disc...@a.o.  The good/evil thing, 
while clearly seeming stupid, should be reviewed by someone on the legal 
committee at the ASF.  I'll forward there.


On Jul 11, 2010, at 7:03 PM, karl.wri...@nokia.com karl.wri...@nokia.com 
wrote:

 Is the JSON license acceptable by Apache?  It seems to be a variant of the 
 Berkeley license:
 
 
 Copyright (c) 2002 JSON.org
 Permission is hereby granted, free of charge, to any person obtaining a copy 
 of this software and associated documentation files (the Software), to deal 
 in the Software without restriction, including without limitation the rights 
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
 copies of the Software, and to permit persons to whom the Software is 
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in 
 all copies or substantial portions of the Software.
 The Software shall be used for Good, not Evil.
 THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
 SOFTWARE.
 
 
 Karl
 



[jira] Commented: (CONNECTORS-56) All features should be accessible through an API

2010-07-14 Thread Jack Krupansky (JIRA)

[ 
https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888377#action_12888377
 ] 

Jack Krupansky commented on CONNECTORS-56:
--

Some cURL and/or Perl test scripts to illustrate use of the API would be 
helpful.

 All features should be accessible through an API
 

 Key: CONNECTORS-56
 URL: https://issues.apache.org/jira/browse/CONNECTORS-56
 Project: Lucene Connector Framework
  Issue Type: Sub-task
  Components: Framework core
Reporter: Jack Krupansky

 LCF consists of a full-featured crawling engine and a full-featured user 
 interface to access the features of that engine, but some applications are 
 better served with a full API that lets the application control the crawling 
 engine, including creation and editing of connections and creation, editing, 
 and control of jobs. Put simply, everything that a user can accomplish via 
 the LCF UI should be doable through an LCF API. All LCF objects should be 
 queryable through the API.
 A primary use case is Solr applications which currently use Aperture for 
 crawling, but would prefer the full-featured capabilities of LCF as a 
 crawling engine over Aperture.
 I do not wish to over-specify the API in this initial description, but I 
 think the LCF API should probably be a traditional REST API., with some of 
 the API elements specified via the context path, some parameters via URL 
 query parameters, and complex, detailed structures as JSON (or similar.). The 
 precise details of the API are beyond the scope of this initial description 
 and will be added incrementally once the high-level approach to the API 
 becomes reasonably settled.
 A job status and event reporting scheme is also needed in conjunction with 
 the LCF API. That requirement has already been captured as CONNECTORS-41.
 The intention for the API is to create, edit, access, and control all of the 
 objects managed by LCF. The main focus is on repositories, jobs, and status, 
 and less about document-specific crawling information, but there may be some 
 benefit to querying crawling status for individual documents as well.
 Nothing in this proposal should in any way limit or constrain the features 
 that will be available in the LCF UI. The intent is that LCF should continue 
 to have a full-featured UI, but in addition to a full-featured API.
 Note: This issue is part of Phase 2 of the CONNECTORS-50 umbrella issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (CONNECTORS-60) Agent process should be started automatically

2010-07-14 Thread Karl Wright (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright updated CONNECTORS-60:
--

   Priority: Minor  (was: Major)
Description: 
LCF as it exists today is a bit too complex to run for an average user, 
especially with a separate agent process for crawling. LCF should be as easy to 
run as Solr is today. QuickStart is a good move in this direction, but the same 
user-visible simplicity is needed for full LCF. The separate agent process is a 
reasonable design for execution, but a little too cumbersome for the average 
user to manage.

Unfortunately, it is expected that starting up a multi-process application will 
require platform-specific scripting.

Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue.

KDW - this functionality is already present; however the documentation is not 
adequate to help people figure out how to do it.  So I'm moving this to 
Documentation and treating it as a doc bug.


  was:
LCF as it exists today is a bit too complex to run for an average user, 
especially with a separate agent process for crawling. LCF should be as easy to 
run as Solr is today. QuickStart is a good move in this direction, but the same 
user-visible simplicity is needed for full LCF. The separate agent process is a 
reasonable design for execution, but a little too cumbersome for the average 
user to manage.

Unfortunately, it is expected that starting up a multi-process application will 
require platform-specific scripting.

Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue.


Component/s: Documentation
 (was: Framework agents process)

 Agent process should be started automatically
 -

 Key: CONNECTORS-60
 URL: https://issues.apache.org/jira/browse/CONNECTORS-60
 Project: Lucene Connector Framework
  Issue Type: Sub-task
  Components: Documentation
Reporter: Jack Krupansky
Priority: Minor

 LCF as it exists today is a bit too complex to run for an average user, 
 especially with a separate agent process for crawling. LCF should be as easy 
 to run as Solr is today. QuickStart is a good move in this direction, but the 
 same user-visible simplicity is needed for full LCF. The separate agent 
 process is a reasonable design for execution, but a little too cumbersome for 
 the average user to manage.
 Unfortunately, it is expected that starting up a multi-process application 
 will require platform-specific scripting.
 Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue.
 KDW - this functionality is already present; however the documentation is not 
 adequate to help people figure out how to do it.  So I'm moving this to 
 Documentation and treating it as a doc bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CONNECTORS-59) Packaged app ready to run with embedded Jetty app server

2010-07-14 Thread Karl Wright (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright resolved CONNECTORS-59.
---

Resolution: Fixed

I am unaware of any lingering issues with the QuickStart work.


 Packaged app ready to run with embedded Jetty app server 
 -

 Key: CONNECTORS-59
 URL: https://issues.apache.org/jira/browse/CONNECTORS-59
 Project: Lucene Connector Framework
  Issue Type: Sub-task
  Components: Framework core
Reporter: Jack Krupansky

 Many potential users of LCF are not necessarily sophisticated developers who 
 are prepared to work with code, but are able to install packaged software, 
 much as Solr is currently distributed. QuickStart for LCF is a good move in 
 this direction, but similar packaging is needed for full LCF with a 
 production database server. This issue focuses on assuring that full LCF is 
 released as a packaged app suitable for download and immediate use without 
 any additional software development expertise required.
 Database packaging has already been called out as a distinct issue 
 (CONNECTORS-55), so this issue is more of a catch-all for any lingering work 
 needed to address support for full LCF as a packaged app.
 Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.