Re: [colorforth] A request for CF code & data for the CF block server

["pattenre" <pattenre@xxxxxxxxxxx>]

I would setup a 32 block private read write block area for each user with
the ability to publish finished blocks in read only public portion of the
disk. Access to privete  areas is by absolute block number and first word in
block if they don't match ignore user packets for 5 minutes. If they match
shift remainder of block up 2 cells and write users IP address in cell 1
datetime in cell 2 after password in cell 0. Allow read write block access
to blocks offset of 0 through 31 from IP address in list on block 0 . This
will allow access control logging. Unused user area passwords could be set
to "color"allowing immediate logon write access by anyone knowing the
default password. Giving your block number and password to others will allow
teem development. When code on block is stable publish to associated public
block.   Make "load"  relative on server  set absolute block with (  n- ) "
parcel"

----- Original Message -----
From: "Tim Neitz" <tim@xxxxxxxxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Sunday, June 22, 2003 5:14 AM
Subject: [colorforth] A request for CF code & data for the CF block server


> ,
> ,
> ,
> Dear cflist, Tim here.
>
> I am sending this mail to ask others to contribute colorforth code and
data
> to this project. This code and data will then be hosted on the public
> colorforth block server. It will serve blocks via the get and put
utilities
> that were released recently in the file bs-client.blk. This means that one
> can store any type of data on this server using the internet. If this code
> is being hosted a URL is enough. For code that is not on the net please
send
> to: tim@xxxxxxxxxxxxxx all code and data are welcome. I will only host
code
> or data that is intended to be public by the contributors. For that reason
> even if you have a well known site, If you want your code hosted here a
> reply will be needed. Again in the reply a URL is enough for code that is
on
> the net. You are also very welcome to contribute code even if you have no
> use for this server.
>
> This colorforth based server is on the internet and has at the moment
about
> 8 megabytes of storage. Later much more room will be available. I will in
a
> seperate mail ask for input on the access system that should be
implemented
> to let us manage this better. These things will take time. For now I
propose
> the following scheme or something just as simple:
>
> We could reserve blocks 0-10 for an index of who is using which blocks.
They
> could be in simple text like in this example below:
>
> This supports a per person load screen concept, that would make ones
> applications be launchable by loading that block. A status entry could
> indicate code being worked on currently. Yielding something like.
>
> User range load block status
> ======================================================
> Bob blocks 100 - 300 100 ready
> Susan blocks 301 - 400 301 busy
> Fred blocks 401 - 1000 469 ready
> Henry blocks 1001 - 1200 1001 busy
>
>
> Concurrent editing of these index blocks would still be a problem. I do
> think it is an acceptable starting point.
>
> Further we would then be carefull to not access blocks from another
persons
> area for writing. This is indeed inadequate for a production server, but
> will start the process of server access features of this block server. It
> would also be easy to adjust the client for ones offset. This would let
them
> think that it is a range from 0 - max-blocks-this-user. I also suggest
that
> we keep local copies of our work. This server will be reliable, and will
get
> backed up. But this project is in an early stage.
>
>
> Server development status is as follows:
>
> The server has been up for several days now, I can access it from home,
and
> use it daily. At this point the server is not backed up, It is also not
> populated. The plan at hand is to back this system up to a second cf
machine
> via the internet, this machine will then write the archive to ide disk.
This
> machine is in a seperate building from the server. I am starting this as
my
> next colorforth task. It should not cause in itself an interruption of
> service. Until then local copies are a must to prevent data loss. Further
> some small changes would be needed to support the access scheme mentioned
> above. I will wait for feedback, and then implement the changes if any are
> suggested. If none are suggested I will start with the scheme that I have
> presented here. Please keep in mind that at the moment I need to choose
for
> something easy to implement. Later there will be a more robust access
> system. This more robust system will take month's in total to finish due
to
> my busy schedule. I am looking for the best easy method until then. This
> will allow others to gain the benefits of this server now. Some of these
> advantages are subtle, but really helpfull. It has for me almost
eliminated
> the swapping of floppies. I use a standard client floppy and get/develop
the
> code from the server. It also allows me to write protect the floppy disk.
> This makes crash recovery much better, the client will "always" reboot.
The
> code that caused the client crash will still be on the server to try
> again...
>
> With kind regards,
>
> Tim Neitz.
> rj_cf on #c4th IRCnet
> tim@xxxxxxxxxxxxxx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com