lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Windows RT / WP8 Version
Date Thu, 22 Aug 2013 05:01:48 GMT
Woah, this thread blew up.  Did not expect that.  :)

I know that it would be a massive amount of work to maintain two versions,
but I think that it is doable over a long stretch of time.  I agree with
you almost completely, particularly regarding it not being possible to do a
full port of it...I can only plan on doing a subset of the most used
features.  I do think that it should definitely stay a part of the Apache
Lucene.Net project, albeit in a different branch that only pulled in the
changed from the main 4.x port.  I like Michael's suggestion on handling
this.

I am very aware (and glad!) of the requirement to have non-blocking methods
in a WinRT version of the library...it was part of my inspiration to bring
up this topic again of multiple platform support.  I think that Lucene.Net
needs async everywhere, regardless of the platform.  We need to be able for
our users to build scalable and asynchronous software, and we should
definitely allow them to use new language features in C# 5.  Really, all of
our methods involving I/O should be asynchronous, and our existing blocking
methods should just call the async ones (well, of course it's more
complicated than _that_ ;)

@Zachary,

Is Xamarin planning on doing a PCL compatible release?  If so, is that
wayyyy far off in the future or relatively soon?  That could influence a
decision in which option to take.  The PCL has the advantage of being able
to reduce the number of conditional pragmas you need in the codebase.

-------------------------

Glad to see that there's interest here.  I like the idea of having the
branches go in parallel.  Either way, I think there needs to be some level
of a design discussion before work can get really get going on this.  If
the PCL is the way to go, then we would need a discussion on what core
pieces would need to be included in the portable library, and what would be
implementation specific.

Thanks,
Christopher


P.S.

@Michael, The website update only took a few minutes.  There was a build
failure because a perl module was no longer valid since the last time we
updated the website, but once I removed it, it built fairly quickly.


On Wed, Aug 21, 2013 at 3:52 PM, mherndon michael <
mherndon@michaelherndon.com> wrote:

> @Chris, thanks for updating the site.  How long did it take for the update
> to the site to complete?
>
> @Paul
>
> To my knowledge, one would not use conditional compilation symbols or
> pragma statements to support target platforms in a PCL, Portable Class
> Library, project.
>
> One would code against the subset of shared APIs that exist for the lowest
> common denominator of the various profiles that are selected and then
> implement things as needed.
>
> @All
>
> PCL
>
> A first pass at using PCL would most likely be done by splitting the core.
>  Place all the interfaces and classes that use the shared APIs in one
> assembly.
>
> The second assembly could just target the full framework for classes that
> would take too long to implement right now.
>
> From there we could go a couple of ways.  Work towards getting everything
> into a core PCL library, or just get enough of it to work in the PCL core
> to provide a limited number of scenarios for other platforms.
>
> GIT
>
> One of the biggest advantages of moving the project to git was to take
> advantages of branching and merging.  Rather than have another long chain
> of debate, let people work on things that keeps them motivated and excited
> which will keep the project moving forward.
>
> I suggest we create two branches.
>
> fast_port_4x  -
> experimental_4x  -
>
> The fast port would be for paul's contribution to date.  As previously
> noted, it currently lacks the tests, documentation, and testing from the
> release audit tool to put it directly into trunk at the moment, but we
> should probably get that into the official repo sooner rather than later.
>
> The experimental_4x could be the targeted approach to attempting PCL,
> Tasked-based Asynchronous Programming, and .NET 4.5 without impeding the
> rest of the project.
>
> GITHUB
>
> We need to request infra to update the apache github mirror to point to the
> working git repo.
>
>
> suggestions, comments, constructive criticisms are welcome.
>
> -M
>
>
>
>
>
>
>
>
> On Wed, Aug 21, 2013 at 1:13 PM, Zachary Gramana <zgramana@gmail.com>
> wrote:
>
> > Christopher,
> >
> > To add to this discussion, I now work at Xamarin and we are not shipping
> > PCL support just yet. In addition, PCL has 22 different client profile
> > levels. You would have to decide which profile Lucene.Net would support.
> My
> > guess is Profile18 would be the best starting point from a compatibility
> > perspective, but that's limiting consumers to SL4 + .NET 4.0. I agree
> that
> > there appeal in a PCL version, but at this point, you're not likely to
> get
> > the payoff that you are hoping for.
> >
> > For a porting to Xamarin.iOS, Xamarin.Android, and Xamarin.Mac, I would
> > recommend other strategies. For example, our Component system will let
> you
> > ship a version of your assembly that doesn't link against monotouch.dll
> but
> > is otherwise compliant to subset of .NET we provide. This is sort of an
> > ersatz PCL, if you will. I suspect that this can be done without
> littering
> > up the codebase with a lot of pragmas.
> >
> > Packaging Lucene.net and getting it on our store has been on my todo list
> > for a while, so if you want some assistance, let me know.
> >
> > Cheers,
> > Zack
> >
> > On Aug 20, 2013, at 10:49 PM, Christopher Currens <
> currens.chris@gmail.com>
> > wrote:
> >
> > > Hey guys,
> > >
> > > I've been thinking lately of doing a real push to have Lucene.Net
> support
> > > more platforms, specifically Windows RT and Windows Phone 8.  There are
> > two
> > > ways I can think of doing it, and each has its own specific advantages
> > and
> > > disadvantages.
> > >
> > > One way, would be to utilize the Portable Class Libraries in VS 2012,
> and
> > > target .NET Framework and Windows Phone (this would also give us
> > > Silverlight).  We could leave the core pieces of Lucene.Net in that
> > > library, and then have platform specific libraries that will share the
> > > code.  This has a convenience advantage at the cost of fragmenting our
> > code
> > > base a little bit, since some parts will be spread across different
> > > assemblies.  We'd probably need to make a platform abstraction layer
> > which
> > > might involve changing some core types to have abstract base classes
> that
> > > could be implemented by each platform assembly.
> > >
> > > Another way, would be to manage it ourselves using different projects.
> >  The
> > > source code could stay in it's existing place, and we'd add links to
> each
> > > source file in the project (instead of having it copy to each
> directory).
> > > Then, each edit we make to a file would work against all of the
> projects
> > > that link that file at the same time.  For platforms that don't support
> > > certain features (one current example is ParallelSearcher only working
> on
> > > 4.0+ and not 3.5), they just don't link that file.  However, we still
> > have
> > > to make sure that the files we do link are cross-platform.
> > >
> > > I actually don't know which one I prefer, I either need to give it more
> > > thought or just choose one, see if I hate it, and switch.  The problem
> > with
> > > the Portable Class Library projects is that they aren't supported in
> > > express editions of Visual Studio.
> > >
> > >
> > > Comments?
> > >
> > >
> > > Thanks,
> > > Christopher
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message