Em Mon, 07 Mar 2011 01:37:44 -, Stas Malyshev smalys...@sugarcrm.com
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
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
Em Mon, 07 Mar 2011 01:15:47 -, Stas Malyshev smalys...@sugarcrm.com
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(),
hi,
On Mon, Mar 7, 2011 at 10:29 AM, Gustavo Lopes glo...@nebm.ist.utl.pt 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
Em Mon, 07 Mar 2011 09:18:24 -, Stas Malyshev smalys...@sugarcrm.com
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
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
On Mon, Mar 7, 2011 at 10:44 AM, Stas Malyshev smalys...@sugarcrm.com 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
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
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
impossible
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
Em Mon, 07 Mar 2011 09:51:31 -, Stas Malyshev smalys...@sugarcrm.com
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
On Mon, Mar 7, 2011 at 10:54 AM, Stas Malyshev smalys...@sugarcrm.com 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
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,
Em Mon, 07 Mar 2011 17:49:54 -, Stas Malyshev smalys...@sugarcrm.com
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
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
hi,
On Mon, Mar 7, 2011 at 6:49 PM, Stas Malyshev smalys...@sugarcrm.com 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
On Mon, Mar 7, 2011 at 7:31 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
On Mon, Mar 7, 2011 at 8:45 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
On Mon, Mar 7, 2011 at 10:09 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
On Mon, Mar 7, 2011 at 10:17 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
On Mon, Mar 7, 2011 at 10:32 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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,
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
26 matches
Mail list logo
