Hi!
Here's an RFC:
http://wiki.php.net/rfc/streammetadata
Patch link inside.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3/8/11 9:40 AM, Pierre Joye wrote:
> On Tue, Mar 8, 2011 at 6:37 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> implemantions/features or breaking compatibility? There is no need to
>>> hurry with that only because it suddenly became very important for a
>>> couple of you. Let think before coding, once
On Tue, Mar 8, 2011 at 6:37 PM, Stas Malyshev wrote:
> Hi!
>
>> implemantions/features or breaking compatibility? There is no need to
>> hurry with that only because it suddenly became very important for a
>> couple of you. Let think before coding, once, would rock :)
>
> If "not hurrying" means s
Hi!
implemantions/features or breaking compatibility? There is no need to
hurry with that only because it suddenly became very important for a
couple of you. Let think before coding, once, would rock :)
If "not hurrying" means sitting and doing nothing until a better
solution magically emerge
On Tue, Mar 8, 2011 at 5:15 PM, Pierre Joye wrote:
> On Tue, Mar 8, 2011 at 5:08 PM, Ferenc Kovacs wrote:
>
> > if you have a better alternative which is viable, then I would support
> that.
> > otherwise I wouldn't support the all-or-nothing approach.
> > thats like if we couldn't add pecl/phpi
On Tue, Mar 8, 2011 at 5:08 PM, Ferenc Kovacs wrote:
> if you have a better alternative which is viable, then I would support that.
> otherwise I wouldn't support the all-or-nothing approach.
> thats like if we couldn't add pecl/phpize until it works on every supported
> platform/filesystem combi
On Tue, Mar 8, 2011 at 1:55 PM, Pierre Joye wrote:
> On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote:
>
> > From the sideline:
> > 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
> > ab
On Tue, Mar 8, 2011 at 4:59 PM, James Butler
wrote:
>
> **
>
> On 08/03/11 15:46, Matthew Weier O'Phinney wrote:
>> On 2011-03-08, Pierre Joye wrote:
>>> On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote:
>>>
From the sideline:
it's hard to belive that there are no one else with opi
**
On 08/03/11 15:46, Matthew Weier O'Phinney wrote:
> On 2011-03-08, Pierre Joye wrote:
>> On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote:
>>
>>> From the sideline:
>>> 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 do
On Tue, Mar 8, 2011 at 4:46 PM, Matthew Weier O'Phinney
wrote:
> and having a way to tie into touch and chmod in my stream wrappers would be
> incredibly useful -- even if it won't work with _every_ stream.
My point was not that it won't work with any stream, obviously. But
that it won't work o
On Tue, Mar 8, 2011 at 4:46 PM, Matthew Weier O'Phinney
wrote:
> As a developer, in many cases I'd prefer something incomplete and limited in
> support to nothing at all. I've been bitten by the same issue Stas describes,
> and having a way to tie into touch and chmod in my stream wrappers would
On 2011-03-08, Pierre Joye wrote:
> On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote:
>
> > From the sideline:
> > 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
On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote:
> From the sideline:
> 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,
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
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!
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: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!
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: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!
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 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!
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 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,
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
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
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!
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
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!
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
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
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 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
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 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
34 matches
Mail list logo
