On Sep 16, 2010, at 6:59 PM, "Spencer E. Olson" <[email protected]> wrote:
> From the users' point of view, practically speaking, another advantage for
> not
> writing these back is that a user could start up processes that create these
> sockets/pipes from multiple locations without disruption.
>
> If you have sockets/named pipes written back to the server, can they really
> be
> used from multiple clients? The idea of "distributed sockets/named pipes" as
> Tom Keiser pointed out would require implementation in the file server, i.e.
> socket/pipe data to be sent accross the file server (wouldn't it?). It also
> seems that this kind of solution would require some new type of knowledge on
> the part of the software that reads/writes to/from the sockets/pipes. This
> seems a bit more of a stretch in terms of purpose/goals of AFS.
>
I can see wanting distributed sockets/pipes and letting AFS distribute, just
not for the same purpose
> On Thursday 16 September 2010 10:32, Derrick Brashear wrote:
>> The point of not writing back is that it can be done today without protocol
>> change. No issue of what unsuspecting clients see, because what they see is
>> ... nothing.
>>
>> On Sep 16, 2010, at 3:53 PM, Andrew Deason <[email protected]> wrote:
>>> On Thu, 16 Sep 2010 07:53:59 -0400
>>>
>>> chas williams - CONTRACTOR <[email protected]> wrote:
>>>> On Thu, 16 Sep 2010 09:58:22 +0200
>>>>
>>>> Derrick Brashear <[email protected]> wrote:
>>>>> 2) if created locally they would cover a later file of the same name
>>>>> if one is created
>>>>
>>>> how about a new 'file type' that is 'special' just like mounts.
>>>> however, they would only have a local (to the client host)
>>>> meaning. old clients would see 'files' (with a strange prefix i
>>>> guess) and new clients would be able to handle these things as special
>>>> devices (named pipes and the like).
>>>
>>> Old clients could write stuff to that file, though, which is also thus
>>> hidden from new clients. Unless you add knowledge about the special
>>> prefix or whatever to the fileserver, prohibiting such.
>>>
>>> We can't create an actual new file type? (as in, an
>>> AFSFetchStatus.FileType type)
>>>
>>> --
>>> Andrew Deason
>>> [email protected]
>>>
>>> _______________________________________________
>>> OpenAFS-devel mailing list
>>> [email protected]
>>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>>
>> _______________________________________________
>> OpenAFS-devel mailing list
>> [email protected]
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
> _______________________________________________
> OpenAFS-devel mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
