<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 1:30 PM, Manik Surtani <span dir="ltr"><<a href="mailto:msurtani@redhat.com" target="_blank">msurtani@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 10 Apr 2013, at 20:57, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
<br>
> Right, let's keep this to collecting requirements:<br>
<br>
</div>+1. Ok, so it seems we're all pretty much in agreement that metadata extraction and indexing should happen on the server side and not on the client. As I said before, this is good. Simple clients, support for re-indexing, support for changes in indexing characteristics, and the ability to save the world from AIDS.<br>
<br>
This puts a requirement on an efficient and portable serialisation format. Again, +1 to starting with defining what we need. Good start below, Sanne.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Besides the serialization format, how do we want to define the indexes on the server?<br><br>Relying on Java classes with Lucene annotations on them doesn't sound like it would support indexing changes very well, because each node would index whatever annotations it had loaded at the moment. So I guess we need a separate indexing configuration, modifiable at runtime, and with annotations as a backup.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> - being able to upgrade the server without losing data<br>
> - being able to change the (soft) schema on the server<br>
> - read/write fields from different languages<br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> - deal with multi-version control of values (i.e. being able to read<br>
> an older value through an evoluted schema, doing comparisons of same<br>
> value even if it was stored using different schema generations)<br>
<br>
</div>I'd add:<br>
<br>
* Support for fast and easy translation to/from object model in high level language of choice (i.e., not manual parsing! Maybe some form of tooling, like a Maven plugin, to generate "IDL"-esque format)<br>
* Serialisation efficiency (size and speed) should be considered<br>
<br>
And in addition, I'd also list out existing technologies that fulfil some or all of these requirements that we can consider, look at extending, etc.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I'd add support for random access for reads. If the user only needs to index a Person's date of birth, it would be nice if we could read only the dateOfBirth field and index that. <br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
- Manik<br>
</font></span><div class="im HOEnZb"><br>
--<br>
Manik Surtani<br>
<a href="mailto:manik@jboss.org">manik@jboss.org</a><br>
<a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a><br>
<br>
Platform Architect, JBoss Data Grid<br>
<a href="http://red.ht/data-grid" target="_blank">http://red.ht/data-grid</a><br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>