[JBoss JIRA] Created: (DNA-114) Create MS Office file sequencer
by Randall Hauch (JIRA)
Create MS Office file sequencer
-------------------------------
Key: DNA-114
URL: http://jira.jboss.com/jira/browse/DNA-114
Project: DNA
Issue Type: Task
Components: Sequencers
Reporter: Randall Hauch
Fix For: 0.2
Create a single sequencer that is capable of sequencing the MS Office files, including MS Word, MS Excel, and MS PowerPoint. All of the files' standard metadata (author, title, word count, page count, etc.) should be extracted, as should metadata specific to the different kinds of files. For example, the sequencer should extract all of the content of the Excel spreadsheets, while it should extract at least the slide titles (and ideally thumbnails).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 2 months
[JBoss JIRA] Created: (DNA-261) Improve how Binary values are created and managed
by Randall Hauch (JIRA)
Improve how Binary values are created and managed
-------------------------------------------------
Key: DNA-261
URL: https://jira.jboss.org/jira/browse/DNA-261
Project: DNA
Issue Type: Feature Request
Components: Graph
Reporter: Randall Hauch
Priority: Minor
Fix For: 0.4
The current InMemoryBinaryValueFactory is creating separate InMemoryBinary objects each time 'create(...)' is called. We should have a Binary factory (and corresponding Binary implementations) that caches the in-memory values using the content's hash as a key. While this may slightly degrade performance (since the hash would be computed immediately rather than lazily if needed), it could result in more efficient use of memory. Note that we'd probably have to use weak or soft references inside the Binary object to the cached values, so that as the Binary objects are garbage collected, the cache can remove the unused values.
Another potential improvement is to store large values on disk, and to memory-map them using direct buffers. This would keep large values (e.g., gigabyte-sized values, such as those used to represent very large files) out of memory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (DNA-260) Add factory method to create a Binary instance from a (local) File
by Randall Hauch (JIRA)
Add factory method to create a Binary instance from a (local) File
------------------------------------------------------------------
Key: DNA-260
URL: https://jira.jboss.org/jira/browse/DNA-260
Project: DNA
Issue Type: Feature Request
Components: API, Graph
Affects Versions: 0.3
Reporter: Randall Hauch
Priority: Minor
Fix For: 0.4
A client sometimes has a file and wants to represent the content of the file with a Binary value object. Currently, the client would have to obtain an InputStream or a Reader to the file, and create the Binary value object with that. Then, when somebody wants to read the binary value, they have to create another stream/reader. Essentially, the content is streamed 1+n times, where n is the number of times the value is read. This can be very expensive when the size of the file is large (or very large, as in gigabytes).
By adding a factor method that takes a File object, the factory could optimize the behavior. Rather than creating a stream/reader to put the content into the Binary value object, the factory could just create a Binary implementation that delegates to a File. Then, the only time a stream/reader is created is when the client wants to read the value. In other words, the content is streamed only n times.
We don't yet have a BinaryFactory interface, and are currently using ValueFactory<Binary>. Therefore, the first step is to create the BinaryFactory interface and use this in the ValueFactories interface. (Most uses of the 'getBinaryFactory()' method would not need to change, since they're either just immediately calling 'create(...)' on the returned reference, or are using ValueFactory<Binary>, which would still work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 3 months
[JBoss JIRA] Created: (DNA-266) Improve usability of graph API with additional methods
by Randall Hauch (JIRA)
Improve usability of graph API with additional methods
------------------------------------------------------
Key: DNA-266
URL: https://jira.jboss.org/jira/browse/DNA-266
Project: DNA
Issue Type: Feature Request
Components: API, Graph
Affects Versions: 0.3
Reporter: Randall Hauch
Assignee: Randall Hauch
Priority: Minor
Fix For: 0.4
Provide an easy way to set references to nodes as property values. Currently, one has to get the node, obtain a reference value factory, create the reference, then set the property using that value. It's pretty impossible to make a single chained call that does all this.
Also, provide additional flexibility when setting properties. Currently, the only way to set a property is to do the following:
graph.set("propName").to("value").on("/node1");
but it would also be nice to reverse the "on" and "to" methods, such as:
graph.set("propName").on("/node1").to("value");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 4 months
[JBoss JIRA] Commented: (DNA-40) Create connector to store any content in a relational database
by Randall Hauch (JIRA)
[ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.... ]
Randall Hauch commented on DNA-40:
----------------------------------
Per JSR-283 section 5.1.7, corrected this connector's copy behavior for how "internal" references (from nodes within the subgraph to nodes also within the subgraph) are remapped in the copy, so that the copy's references are also internal to the copy. Also verified that "outward" references (from nodes within the subgraph to nodes outside of the subgraph) are copied correctly, and that "inward" references (from nodes outside of the original subgraph to nodes in the original subgraph) are not affected by the copy operation (since the original subgraph is not modified).
Note that JSR-170 does not define the semantics of how references are handled in a copy operation.
> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
> Key: DNA-40
> URL: https://jira.jboss.org/jira/browse/DNA-40
> Project: DNA
> Issue Type: Feature Request
> Components: Connectors
> Reporter: Randall Hauch
> Assignee: Randall Hauch
> Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema. This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 4 months
[JBoss JIRA] Commented: (DNA-40) Create connector to store any content in a relational database
by Randall Hauch (JIRA)
[ https://jira.jboss.org/jira/browse/DNA-40?page=com.atlassian.jira.plugin.... ]
Randall Hauch commented on DNA-40:
----------------------------------
Completed the connector's method to process branch copy requests, and added more unit tests. Fixed a bug in the CopyBranchRequest class - when setting the actual locations, the request was incorrectly checking that the actual location matched that of the "into" location (which is the parent of the new copy), rather than the actual location of the new copy.
> Create connector to store any content in a relational database
> --------------------------------------------------------------
>
> Key: DNA-40
> URL: https://jira.jboss.org/jira/browse/DNA-40
> Project: DNA
> Issue Type: Feature Request
> Components: Connectors
> Reporter: Randall Hauch
> Assignee: Randall Hauch
> Fix For: 0.4
>
>
> Create a federation connector that is able to manage information in a relational database using a DNA-defined schema. This would enable the persistant storage of information that isn't being managed by other connectors.
> Requirements include efficiently storing and accessing large numbers of nodes, large property values (e.g., Binary values), and large numbers of children on nodes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 4 months