thanks for the changes, however I'll need to evaluate them in light of changes of ...
7 years, 5 months ago
(2016-11-24 16:09:40 UTC)
#2
thanks for the changes, however I'll need to evaluate them in light of changes
of https://codereview.appspot.com/303250043/ so I might come with a counter
proposal based on these changes.
On 2016/11/24 16:09:40, Joachim Metz wrote: > thanks for the changes, however I'll need to ...
7 years, 4 months ago
(2016-12-06 13:59:49 UTC)
#3
On 2016/11/24 16:09:40, Joachim Metz wrote:
> thanks for the changes, however I'll need to evaluate them in light of changes
> of https://codereview.appspot.com/303250043/ so I might come with a counter
> proposal based on these changes.
Sounds good. However, I don't think my changes will affect the changes you made
in that review.
(The reason for this change is for the analysis reports that I am creating which
contain attribute containers such as event objects and path specs.)
On 2016/11/24 16:09:40, Joachim Metz wrote: > thanks for the changes, however I'll need to ...
6 years, 11 months ago
(2017-05-09 13:29:52 UTC)
#4
On 2016/11/24 16:09:40, Joachim Metz wrote:
> thanks for the changes, however I'll need to evaluate them in light of changes
> of https://codereview.appspot.com/303250043/ so I might come with a counter
> proposal based on these changes.
Any updates on this?
Let me give this some thought. One of the idea I'm playing with is not ...
6 years, 11 months ago
(2017-05-10 05:48:40 UTC)
#6
Let me give this some thought. One of the idea I'm playing with is not to store
/ serialize attribute containers embedded but storing relationships in a
different way (e.g. semantic triple) to do more with these.
On 2017/05/10 05:48:40, Joachim Metz wrote: > Let me give this some thought. One of ...
6 years, 11 months ago
(2017-05-10 16:34:46 UTC)
#7
On 2017/05/10 05:48:40, Joachim Metz wrote:
> Let me give this some thought. One of the idea I'm playing with is not to
store
> / serialize attribute containers embedded but storing relationships in a
> different way (e.g. semantic triple) to do more with these.
No problem. Having the ability form relationships between AttributeContainers is
a very desired feature for us. We have been exploring ways to connect
EventObjects created by different parsers together (e.g. a message event from
one database with the sender's account/contact information from another database
or preference file.)
Our current use for serializing embedded AttributeContainers is to provide
support for attachment information (stored as its own AttributeContainer) inside
the EventObjects containing message data. The attachment container stores
information such as filename, mime_type, and a path_spec pointing to the
attachment file in cache.
It would be better if the attachments were their own EventObject with a
relationship to the message event.
Per recent changes to SQLite storage. I'll not add the functionality to store attribute containers ...
6 years, 3 months ago
(2018-01-26 06:34:43 UTC)
#8
Per recent changes to SQLite storage. I'll not add the functionality to store
attribute containers (AC) inside ACs but prefer to use AC identifier approach
instead. Such as with event data. This approach is still evolving but reduces
the needed storage and should allow us to use more relational database features.
Sorry for the (very) slow response on this but I'll not merge these changes, but
thanks for providing them to us.
Issue 319730043: [plaso] JSON serializer support for AttributeContainers inside AttributeContainers #1085
Created 7 years, 5 months ago by dc3.plaso
Modified 6 years, 3 months ago
Reviewers: Joachim Metz, jberggren, romaing, onager
Base URL:
Comments: 0