Good point!! There is similar issue around escaping in JSON for values in
maps, which needs to be addressed. I guess the same mechanism could be used
to escape XML tagnames as well.
Niclas
On Mon, Jul 13, 2015 at 1:49 PM, Paul Merlin p...@nosphere.org wrote:
Hey,
Java allow UTF-8
[
https://issues.apache.org/jira/browse/ZEST-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Merlin resolved ZEST-44.
-
Resolution: Fixed
Javadocs generation is failing.
---
Key:
Paul Merlin created ZEST-100:
Summary: Document the release process
Key: ZEST-100
URL: https://issues.apache.org/jira/browse/ZEST-100
Project: Zest
Issue Type: Sub-task
Reporter:
Paul Merlin created ZEST-99:
---
Summary: Request svnpubsub for dist.apache.org from INFRA
Key: ZEST-99
URL: https://issues.apache.org/jira/browse/ZEST-99
Project: Zest
Issue Type: Sub-task
Paul Merlin a écrit :
Hey Niclas,
Yep, serialization is pretty straight forward.
Deserialization is a bit more convoluted.
That is to support streamed (de)serialization of large datasets like
giant Entities/Values or large collections of these.
Serialization is always streaming.
Paul Merlin created ZEST-98:
---
Summary: Update Download Page
Key: ZEST-98
URL: https://issues.apache.org/jira/browse/ZEST-98
Project: Zest
Issue Type: Sub-task
Reporter: Paul Merlin
Hey Niclas,
Yep, serialization is pretty straight forward.
Deserialization is a bit more convoluted.
That is to support streamed (de)serialization of large datasets like
giant Entities/Values or large collections of these.
Serialization is always streaming.
Deserialization is streaming by
On Mon, Jul 13, 2015 at 1:58 PM, Paul Merlin p...@nosphere.org wrote:
Any thoughts?
I'm all in favor for going towards Entity=Identity+Value. In the end,
this will allow us to drop a bunch of code as EntityState serialization
in EntityStores is pretty different than ValueSerialization (was
Paul Merlin a écrit :
Moreover, Map keys can be something else than a String, they can be a
Number, a Date et...
And in fact, Maps keys could be a complex type, like some Value.
Niclas Hedhman (JIRA) a écrit :
Thanks for grabbing this...
In light of all things flying around, here are my thoughts;
* Prioritize a release, primarily for publicity reasons.
* I have no features that I insist on pushing into 2.1, since I already
depend on my own branch which has some
I Think i have misunderstood the intention behind timeseries support then.
I was more thinking of timeseries as derived values - the same way that the
indexing May be considered derived from the entity store. And just like in
some architectures the entity may be considered derived from an
11 matches
Mail list logo
