jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: human-readable storage
Date Fri, 06 Dec 2013 13:52:05 GMT
You need to clarify your thinking and start using terminology that is 
accurate.

Paper documents are human readable.
WORM devices are not human readable. They require hardware and software.

1) How long are you wanting to keep the data?
2) Are you prepared to maintain the media while in storage or do you 
intend to keep a device that can read your media? I just trew out the 
last of my 8 inch floppies since I had no way to read them.
3) What would you like a human being who wants to access old data be 
able to do?
Walk through the whole process and think about what you actually have in 
your hands at each step.
- Go to vault and get old WORM media.
- Go to x and get drive that can read this?
- Find UI device - tablet, phone... (PCs probably all gone by then) 
attach drive - how? what interface do you expect to exist on a tablet in 
2020?
- Load app. what app do you need to have available in 2020 for your 
tablet to read your data? device driver for your 7 year old WORM, some 
app that can navigate the WORM file structure and find customer data.
And so on.


If your data has relationships between entities what should a human 
being be able to see with the software that you specify?
Customer has many invoices, invoices have many detail lines, each detail 
line has a link to a product master.
What is the process in 2020 to find out who bought product x?
Will they be able to see the invoices for each customer as well or do 
they need to reconstruct that data from the product lists.

Human readable is not a useful concept in talking about digital data. We 
can only see what some software stack delivers to a media that our eyes 
(or fingers) detect - paper, pixels, braille touch pad.
Jackrabbit is a perfectly good format as long as you retain the software 
stack required to read it and maintain the digital media on devices that 
future technology can read.
Software has an infinite shelf life as long as you maintain the media 
and make sure that you have hardware that can run the stack.


On 06/12/2013 3:10 AM, danisevsky wrote:
> Hi,
>
> I am afraid that webDav is not choice for us. This human-readable storage
> is intended for archiving data for many years. And beside human-readable
> there are some other requirements like using some WORM (
> http://en.wikipedia.org/wiki/Write_once_read_many) for files - which could
> be possible using FileDataStore.
> We don't want to use low-level java.io.File and java.io.FileInputStream
> because we need features like properties and versioning.
> I will look at https://github.com/wyona/yarep.
>
> Thanks!
>
>
>
> 2013/12/5 Michael Wechner <michael.wechner@wyona.com>
>
>> Just to be sure I understand what you are looking for. You are looking
>> for a Java based API to access data, but you don't want to use
>> java.io.File and java.io.FileInputStream, but still you would like to
>> have the data on a regular filesystem, right?
>>
>> If so, then you might also want to try
>>
>> https://github.com/wyona/yarep
>>
>> which basically allows something like the following
>>
>> Repository repo = new RepositoryFactory().newRepository("vfs-example", new
>> File("/home/alice/vfs-example-repository-config.xml"));
>> Node node = repo.getNode("/hello/world.txt");
>> InputStream in = repo.getInputStream();
>>
>> whereas the repository configuration could look like for example
>>
>>
>> https://github.com/wyona/yarep/blob/master/src/test/repository/new-vfs-example/repository.xml
>>
>> and then there is a 1:1 mapping to the data
>>
>>
>> https://github.com/wyona/yarep/tree/master/src/test/repository/new-vfs-example/content
>>
>> HTH
>>
>> Michael
>>
>>
>> Am 05.12.13 18:28, schrieb R. van Twisk:
>>>> Thanks Jukka,
>>>>
>>>> unfortunately it is not acceptable for our customers. They want to be
>> able
>>>> to read files without Jackrabbit.
>>> I never tried this myself, but I think what Jukka means is that you need
>> to use webdav to mount it..
>>> So you simple mount your Jackrabbit store as if it’s just some external
>> disk see : http://savannah.nongnu.org/projects/davfs2
>>> This way your client doesn’t know better than that the file are stored
>> on disk.
>>> Google is your friend to, it gave me this link :
>> http://mail-archives.apache.org/mod_mbox/jackrabbit-users/200811.mbox/%3C491BF00F.2010602@charlie.brooking.id.au%3E
>>>
>>>> Best regards
>>>>
>>>>
>>>> 2013/12/5 Jukka Zitting <jukka.zitting@gmail.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 4, 2013 at 10:48 AM, danisevsky <danisevsky@gmail.com>
>> wrote:
>>>>>> But we need exactly the same structure like is in JCR, e.g:
>>>>>> 2013/vacation/bhutan/DSC01322.jpg
>>>>>>
>>>>>> Is this reachable using Jackrabbit?
>>>>> Yes. The way to do this is to mount the Jackrabbit repository as a
>>>>> network disk using the WebDAV layer.
>>>>>
>>>>> BR,
>>>>>
>>>>> Jukka Zitting
>>>>>
>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


Mime
View raw message