Em Mon, 07 Mar 2011 01:37:44 -, Stas Malyshev
escreveu:
I think a better option would be a function to convert a php socket
stream into a socket resource. That would avoid limiting this to
socket_get_options/socket_set_options and polluting the socket ext
functions prologue with these c
Hi!
I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?
That will indeed give you a socket descriptor, but
1) it's not directly available to user-space.
2) you still have to create a socket extension resource in order to pass
it to functions of that extension.
Em Mon, 07 Mar 2011 01:15:47 -, Stas Malyshev
escreveu:
PHP file streams provide very powerful and useful abstraction layer over
the I/O-related functions. However, there's a group of functions which
are excluded from this support - namely, touch(), chmod(), chown() and
chgrp() - i.e
hi,
On Mon, Mar 7, 2011 at 10:29 AM, Gustavo Lopes wrote:
> But what about getting the metadata (as opposed to setting it)? I understand
> reading most of this stuff is already covered by the stat handler, but what
> about for example NTFS/POSIX ACLs or reading reparse point data? It would be
>
Em Mon, 07 Mar 2011 09:18:24 -, Stas Malyshev
escreveu:
I think we already have PHP_STREAM_AS_SOCKETD, which should be
appropriate here, not?
That will indeed give you a socket descriptor, but
1) it's not directly available to user-space.
2) you still have to create a socket extension r
Hi!
I would prefer to have these particular getters (and maybe ever
setters) somewhere else, like in a derivated SplFile. That would give
us more flexibility and cleaner APIs fro something that does not
really fit in default streams anyway (or rarely).
touch(), chmod(), etc. aren't "rarely" us
On Mon, Mar 7, 2011 at 10:44 AM, Stas Malyshev wrote:
> Hi!
>
>> I would prefer to have these particular getters (and maybe ever
>> setters) somewhere else, like in a derivated SplFile. That would give
>> us more flexibility and cleaner APIs fro something that does not
>> really fit in default str
Hi!
I suppose this information could be queried, but would you want to do the
cast and retrieve this data in every call say in a socket_read loop?
I'd ask why you need socket_read and not just fread if you use streams?
If you need deeper semantics, then yes, either you use resources or you
c
Hi!
The key part of this reply was "these particular", as they are very
platform specific and useless in a generic stream wrapper
implementation.
Every stream wrapper doesn't have to implement them - as it doesn't have
to implement conversion to socket, etc. But without this, it is
impossibl
Hi!
But what about getting the metadata (as opposed to setting it)? I
Most metadata widely used is covered by stat. I.e. for my itch (having
functioning filesystem wrapper) it is not needed. But that doesn't mean
it can't be done for other purposes :)
--
Stanislav Malyshev, Software Archit
Em Mon, 07 Mar 2011 09:51:31 -, Stas Malyshev
escreveu:
I suppose this information could be queried, but would you want to do
the cast and retrieve this data in every call say in a socket_read loop?
I'd ask why you need socket_read and not just fread if you use streams?
If you need d
On Mon, Mar 7, 2011 at 10:54 AM, Stas Malyshev wrote:
> Hi!
>
>> The key part of this reply was "these particular", as they are very
>> platform specific and useless in a generic stream wrapper
>> implementation.
>
> Every stream wrapper doesn't have to implement them - as it doesn't have to
> imp
Hi!
To hear that stream are useless for filesystem operation is very new to me.
It was surprise for me too, nevertheless once you try to use it, you
pretty soon hit this roadblock with any serious application and have to
resort to very ugly hacks.
I have to repeat what I said earlier, th
Em Mon, 07 Mar 2011 17:49:54 -, Stas Malyshev
escreveu:
I have to repeat what I said earlier, these specific informations
(ACL, reparse points or other OS/FS specific informations) are very
Nobody cares about reparse points. There's probably no PHP app in
existence that cares about re
Hi!
There can be certainly no "working and portable" implementation of stuff
like NTFS ACLs on *nix or a useful chmod implementation on Windows and
I am starting to feel you and Pierre are failing to see forest for the
trees. The goal is not to implement every tiny detail of Windows FS
funct
hi,
On Mon, Mar 7, 2011 at 6:49 PM, Stas Malyshev wrote:
> Hi!
>
>> To hear that stream are useless for filesystem operation is very new to
>> me.
>
> It was surprise for me too, nevertheless once you try to use it, you pretty
> soon hit this roadblock with any serious application and have to res
On Mon, Mar 7, 2011 at 7:31 PM, Stas Malyshev wrote:
> I am starting to feel you and Pierre are failing to see forest for the
> trees.
Well, actually I feel like you see one tree only, well two considering
that you see Windows as being the only other tree. That's clearly not
the case :)
Cheers,
Hi!
The more I read what you say the more I think that what you want is
not a working stream implementation to do filesystem ops, but a way to
emulate a virtual file system using stream. I don't think it is the
goal of our stream implementation to do that. Tools like FuseFS are
I think our str
On Mon, Mar 7, 2011 at 8:45 PM, Stas Malyshev wrote:
> Did you just claim you know better than me what is useful for me? Nice :)
No I don't. But I'm telling you that what you propose is incomplete
and bad, to start with.
> But again vfsStream example shows it will be useful not only for myself
Hi!
No I don't. But I'm telling you that what you propose is incomplete
and bad, to start with.
Incomplete - yes. If we only implemented things that are "complete" in
the sense you require, we would have no file operations in PHP at all -
after all, we don't have support for reparse points a
On Mon, Mar 7, 2011 at 10:09 PM, Stas Malyshev wrote:
> Incomplete - yes. If we only implemented things that are "complete" in the
> sense you require, we would have no file operations in PHP at all - after
> all, we don't have support for reparse points and NTFS ACLs in file
> functions now, so
Hi!
only. Get over that first then it will be easier to actually discuss
possible solutions or alternatives.
I saw no possible solutions or alternatives mentioned except for vague
references to FuseFS (which is totally different project, requires
massive investment of time and would have sam
On Mon, Mar 7, 2011 at 10:17 PM, Stas Malyshev wrote:
> Hi!
>
>> only. Get over that first then it will be easier to actually discuss
>> possible solutions or alternatives.
>
> I saw no possible solutions or alternatives mentioned except for vague
> references to FuseFS (which is totally different
Hi!
That was also the reasons why they are not present in our stream
implementation. I could image something for touch (there is a FR for
it afair) as it is very easy to emulate on stream where it could not
work, but really not for ch*.
We have chmod now defined on all systems. However good or
On Mon, Mar 7, 2011 at 10:32 PM, Stas Malyshev wrote:
> Hi!
>
>
> That was also the reasons why they are not present in our stream
>> implementation. I could image something for touch (there is a FR for
>> it afair) as it is very easy to emulate on stream where it could not
>> work, but really no
Hi!
it's hard to belive that there are no one else with opinion on this matter.
I don't want to take sides because I don't have the necessary knowledge
about the matter, but maybe it would be a good idea to write an RFC, and
and maybe a POC, so we can see how intrusive would be the implementatio
26 matches
Mail list logo
