Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@manifoldcf.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CALUFAGA1rFuSEh0sJOmV1w6wzu2dLOt+RNJJGbqO4pdf8YgO1w@mail.gmail.com>
References: 
 <CALUFAGAyVhfP=Yg06K1CgHW4oi87-ziU-3c7CMdb093AOupfJQ@mail.gmail.com>
 <CAEO2op_wFYTwhG8AXjCgThdyU59M4FO3aarCnv0KJcBKVMiRhg@mail.gmail.com>
 <CALUFAGBuZOEUhPh4FUKPyWhT2fZw22pnk1k2=S3oEUqEKbX=1Q@mail.gmail.com>
 <6C9A506B-F3F2-41C4-AC9F-FCCE2788B0A7@gmail.com>
 <1403126791.19027.YahooMailNeo@web124705.mail.ne1.yahoo.com>
 <CALUFAGD0nSbzzaYW_wrSdBQuQdAedoje-N-acw3y=yX3J4qwqQ@mail.gmail.com>
 <CALUFAGDyJ1sXzw1gHDnhywhMRjYXFmKQdB0wQbstq6YJY+9GFw@mail.gmail.com>
 <BC0851F6-669F-4BF9-AB2A-BC40352508E4@gmail.com>
 <CALUFAGA1rFuSEh0sJOmV1w6wzu2dLOt+RNJJGbqO4pdf8YgO1w@mail.gmail.com>
From: Piergiorgio Lucidi <piergiorgio@apache.org>
Date: Thu, 19 Jun 2014 15:24:05 +0200
Message-ID: 
 <CAEO2op9J1QABipNSYLNoutyoqW2STwDT=_GKGdoT=WCd4NNM8Q@mail.gmail.com>
Subject: Re: ManifoldCF 2.0 plans
To: "dev@manifoldcf.apache.org" <dev@manifoldcf.apache.org>
Content-Type: multipart/alternative; boundary=047d7b6728f4b1eefe04fc304b6a

--047d7b6728f4b1eefe04fc304b6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that we have to absolutely provide the following things to users
and developers for a wide adoption of the project:

1. Very easy guides step-by-step to show how to install Manifold in
different environments
2. Publish all the Maven dependencies in the Apache Maven Repo (
https://repository.apache.org/)

Cheers,
Piergiorgio


2014-06-19 10:06 GMT+02:00 Karl Wright <daddywri@gmail.com>:

> Hi Muhammed,
>
> I think it is important that each connector describe its seeding model in
> the most precise way possible.  If you thing GridFS could specify a tight=
er
> seeding model, then by all means create a ticket and fix it.  But I don't
> think it's necessary to wait until MCF 2.0 to do it, since the documents
> returned for MODEL_ALL are a superset of those returned for
> MODEL_ADD_CHANGE.
>
> Thanks,
> Karl
>
>
>
>
> On Thu, Jun 19, 2014 at 3:10 AM, Muhammed Olgun <mh.olgun@gmail.com>
> wrote:
>
> > Hi Karl,
> >
> > I was thinking about may be we can add shards from the job UI. On secon=
d
> > thought it=E2=80=99s out of our scope. User should do it himself/hersel=
f.
> >
> > I thought that good seeding model increasing the MCF performance. GridF=
S
> > connector works with MODEL_ALL. Assume that the user also stores added
> and
> > changed documents=E2=80=99 metadata(or key) in a mongodb collection. If=
 the user
> > wants to select other seeding model, may be we can get from the user a
> > query which returns the added and changed documents then the user can u=
se
> > MODEL_ADD_CHANGE.
> >
> > What do you think?
> >
> > Muhammed
> >
> > On 19 Jun 2014, at 00:40, Karl Wright <daddywri@gmail.com> wrote:
> >
> > > Hi Muhammed,
> > >
> > > Can you go into more depth about these:
> > >
> > >>>>>>>
> > > 1) Sharding support
> > > 2) Selectable seeding model.
> > > <<<<<<
> > >
> > > Thanks,
> > > Karl
> > >
> > >
> > >
> > > On Wed, Jun 18, 2014 at 5:38 PM, Karl Wright <daddywri@gmail.com>
> wrote:
> > >
> > >> bq. What is "non-SQL data store" ? You mean to remove MFC's dependen=
cy
> > to
> > >> PostgreSQL, MySQL, Derby etc?
> > >>
> > >> See CONNECTORS-286.
> > >>
> > >> bq. What do you think about this? Can MCF be dih replacement?  How i=
s
> > our
> > >> DB crawler compared to DIH?
> > >>
> > >> In theory it could.  I'd hesitate before claiming feature-to-feature
> > >> compatibility though, and I'm not sure whether Solr people would
> > officially
> > >> recommend MCF in any case, especially since they have wanted to solv=
e
> > >> document security in their own way (but have never gotten around to =
it
> > in
> > >> the 3+ years this first came to my attention).
> > >>
> > >> Karl
> > >>
> > >>
> > >>
> > >> On Wed, Jun 18, 2014 at 5:26 PM, Ahmet Arslan
> <iorixxx@yahoo.com.invalid
> > >
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> What is "non-SQL data store" ? You mean to remove MFC's dependency =
to
> > >>> PostgreSQL, MySQL, Derby etc?
> > >>>
> > >>>
> > >>> By the way solr guys are looking for a Data Import Handler (DIH)
> > >>> replacement.
> > >>>
> > >>> See for the thread : http://search-lucene.com/m/WwzTb2z1w7F
> > >>>
> > >>> DIH is mostly used to sync RDBMS to Solr.
> > >>>
> > >>> What do you think about this? Can MCF be dih replacement?
> > >>>
> > >>> How is our DB crawler compared to DIH?
> > >>>
> > >>> Ahmet
> > >>>
> > >>>
> > >>> On Wednesday, June 18, 2014 11:33 PM, Muhammed Olgun <
> > mh.olgun@gmail.com>
> > >>> wrote:
> > >>> Hi all,
> > >>>
> > >>> I think that a non-SQL solution would be great. I have also two new
> > ideas
> > >>> for GridFS connector,
> > >>>
> > >>> 1) Sharding support
> > >>> 2) Selectable seeding model.
> > >>>
> > >>> Muhammed
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 18 Jun 2014, at 23:22, Karl Wright <daddywri@gmail.com> wrote:
> > >>>
> > >>>> Hi Piergiorgio,
> > >>>>
> > >>>> Just to clarify -- I don't have a workable plan yet for a non-SQL
> data
> > >>>> store, so maybe that waits until 3.0.
> > >>>>
> > >>>> Karl
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Wed, Jun 18, 2014 at 3:13 PM, Piergiorgio Lucidi <
> > >>> piergiorgio@apache.org>
> > >>>> wrote:
> > >>>>
> > >>>>> +1 from me for breaking backwords compatibility and focusing on
> > non-SQL
> > >>>>> data store.
> > >>>>>
> > >>>>> Piergiorgio
> > >>>>>
> > >>>>>
> > >>>>> 2014-06-18 18:19 GMT+02:00 Karl Wright <daddywri@gmail.com>:
> > >>>>>
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> By now it is becoming clear that ManifoldCF has accumulated a lo=
t
> of
> > >>>>>> backwards-compatibility dead weight we have to carry around from
> > >>> release
> > >>>>> to
> > >>>>>> release.  However, ManifoldCF 2.0 will present an opportunity to
> > break
> > >>>>>> backwards compatibility with the 1.x releases.  Originally, I wa=
s
> > >>>>> thinking
> > >>>>>> that MCF 2.0 would be the proper release vehicle for an
> > >>> implementation on
> > >>>>>> top of a non-SQL data store, but now I am looking at this instea=
d
> > as a
> > >>>>>> great way to clean out deprecated tabs, methods, and even whole
> > >>>>> connectors
> > >>>>>> from the codebase.
> > >>>>>>
> > >>>>>> I'd like to consider making the MCF 2.0 release be the next one
> > after
> > >>>>> 1.7.
> > >>>>>> Since 1.7 is scheduled for end of August, 2.0 would come out som=
e
> > >>> months
> > >>>>>> after that.  Please comment on whether you agree with this basic
> > >>> plan, or
> > >>>>>> you have other priorities we should know about. ;-)
> > >>>>>>
> > >>>>>> FWIW, if this *is* a good idea to you, please also list one or t=
wo
> > >>> main
> > >>>>>> areas we should work on for 2.0 that involve breaking backwards
> > >>>>>> compatibility.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Karl
> > >>>>>>
> > >>>>>> --
> > >>>>>> Piergiorgio Lucidi
> > >>>>>> Open Source ECM Specialist
> > >>>>>> http://www.open4dev.com
> > >>>>>>
> > >>>>>
> > >>>
> > >>
> > >>
> >
> >
>
> --
> Piergiorgio Lucidi
> Open Source ECM Specialist
> http://www.open4dev.com
>

--047d7b6728f4b1eefe04fc304b6a--