Forum .LRN Q&A: Re: LRN Application Status Discussion - File Storage

Let me add a naive view of an author generating data and
putting these data into the file storage.

How should I do it? What do I have to consider for

- the generation of data,
- the uploading process,
- a (partially) replacement of files,
- the using part (by my students) and
- the download feature?

As long as we speak about single (maybe large) files
almost everything is working. The problem starts with
a series of interconnected files where interlinking
is a key feature needed in file storage.

Authors do create the data on there own computer in a
(sub)tree with relative linking - this is the way to
publish it on the web. And we have a mass of these trees
and we must support them within .LRN.

How to upload this tree into .LRN or to replace parts of
it within .LRN keeping the relative linking in good order?
Should I use single file upload? or zip-file upload? or
web-dav? which upload feature can GUARANTEE the relative
linking to work - one or all? Similar problems apply to
the usage and "reverse" problems to the download process.

We need consistency between the external view and the
internal databased management of files - and an easy way
for authors to handle to above processes.

Michael

Although possible, this could be a bit tricky. Say for instance you have the following files in a zip file that you want to share with your students:

[ root folder]
|-> default.html
|-> intro.html
|-> flash_animation.swf
|-> xmlfile.xml
|- [ images folder ]
    |-> randompic1.jpg
    |-> randompic2.jpg

Given this structure, LORS can't really guess or know where the entry points are. We could say, well, maybe the default.html might be the entry point, but again, that's an assumption that we would make.

Now Michael has a very good point here and probably we should clarify the difference between learning objects and plain content.

LORS is good to handle learning objects aggregations (courses) and/or individual learning objects. But if the zip file represented above isn't a learning object neither a course, but a piece of content that I want to share with my students, I shouldn't have to convert it into a learning object by using Reload, creating a content packaging, edit metadata, etc, etc... that'll be rather tedious if I have to do this for each hand out in my class.

Probably an example can ilustrate this better. Say for instance I'm a teacher for a class and on the way to uni on the bus I read this article that relates to the subject I'm teaching today. I might want to add this article as "suggested readings" for the subject. This is not necesarily a learning object as such, but just a random article that might content various pieces that you want to share with your class.

I know -for sure- that File-storage works well linking different pieces of content together using its index.vhu. As a matter of fact LORSm relied on it until recently for all its content delivery -now LORSm has its own.

So summarizing, I think it's good that file-storage still maintains its index.vhu for linking random content that might not necesarily need to be part of a course. It's always good to have that as a choice.

Thanks,

Ernie