At 11:33 8/5/01 -0400, Geir Magnusson Jr. wrote:
>> The content of the envelopes will most likely only be required during
>> installation and deployment stages and if done appropriately each
>> deployment type could just use a different handler/hook.
>
>And if we keep things small, we can bring the factory in from 'afar' for
>the first time, just like any other resource...
yep ;)
>> So if you consider separating meep out like that with majority of methods
>> dealing with resource envelopes rather than directly with resource content
>> it could be very useful in some domain I have in mind ;)
>
>Can you tell us?
The directory bit was going to be a global distributed and replicated LDAP
server.
The retrieval bit was from a distributed file server. I called my prototype
Astech (Assett Sharing TECHnology) - it was basically a distrbuted file
server. You link a bunch of servers together and they share files between
them as their users request them. Much like FreeNet popular files will be
replicated across many nodes and highest density in areas that the files
are most often requested from.
The versioning was basically similar to what meep has combined with
.deb/.rpm format.
The packages would also include a descriptor. The descriptor would have
rdf/other classification and a list of contents. Each content item would
have classification parameters. Parameters would indicate whether the
content was sharable between different machines (ie platform independent),
or machines of same architecture (ie x86 elf), whether it was required
during "boot" time, whether it was a system-wide file or a user-specific
file, user-orientated or admin orientatedetc.
To give a concrete example in unix. The "sh" executable is a system-wide
file sharable by machines of same architecture, required at boot time and
user orientated. So using an algorithm it would be possible to
automatically locate the file as /bin/sh. If it had not been required at
boot time it would go to /usr/bin/sh. if it had been user specific it would
go to ~user/bin/sh, if it had been admin orientated it would go to /sbin/sh
etc.
Now given that the location of files can automatically derived from input
data + a set of rules. Thus we could have one system that was able to
install products no matter what system/os or directory layour scheme you
use. You could use the same system (but different rules) to install win32
binaries aswell.
Now my end reason for doing this is because I wanted to share content and
executables between Virtual Environments (aka VR aka 3-D games) in a
distributed and secure manner (has to be platform independent aswell). It
also has to allow certain parties to "inject" products in the the "cloud"
(yea using MS terminology now) that is the file server. So basically anyone
could upload but it depends on signatures on where, what and how the
uploads can occur.
>> *------------------------------------------------------*
>> | "Computers are useless. They can only give you |
>> | answers." - Pablo Picasso |
>> *------------------------------------------------------*
>
>I liked the other sig... :)
How about the following?
Cheers,
Pete
*------------------------------------------------------*
| Hlade's Law: If you have a difficult task, give it |
| to a lazy person -- they will find an easier |
| way to do it. |
*------------------------------------------------------*
