Re: [PATCH] gobex: Fix setpath to match one from OBEX spec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 16, 2011 at 12:12 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Bartosz,
>
> On Wed, Nov 16, 2011 at 10:24 AM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote:
>>
>> Come on did You even read it?? This function is OBEX level (an it
>> works before in similar way - only one dir at a time) - we may don't
>> like specification, but seriously? Just read the patch, i exposed on
>> OBEX level stuff defined in the OBEX specification (as MAP needs
>> operation like "go one level up and than down" in one step) and as it
>> would be possible to just add some "if" for "../dir" in previous
>> version, but it is better to fix broken things than to propagate them
>> (it's obex level function not high level abstraction - deal with it).
>
> Yeah, lets create an API that we don't use, really? Your MAP API need
> it but that doesn't mean we agree on using it as it is, that table you
> use to explain how it works is already a sign that it is

I guess the table I've seen in Bartek's proposal is rather graphical
representation that serves an example. I think that simply saying that
"cdup" goes up one level before going to child directory would be also
understandable and not really confusing.

> over-engineered and will be easily misinterpreted by applications. We
> will not break MAP by not exposing this complexity since we can still
> do it transparently, even doing cdup and another SetPath although
> inefficient would still work.

The function itself is quite useful for MAP clients. There is this
fixed part of directories structure in MAP, which is:

telecom
 '- msg
     |- inbox
     |- outbox
     |- sent
     |- deleted
     '- draft

There are no messages in msg, thus going from e.g. outbox to sent
directly seems convenient.

I do not understand why you are so reluctant to have function for
setting path in gobex that actually offers what OBEX offers. As I
mentioned already in discussion about MAP API proposal, this also
gives additional restrictions on what characters one can use in folder
name.

You at least have one example of profile that could have make use of
it. So it won't be in effect anything that is not used.

>> Each profile may use it multiple times for paths delivered through
>> dbus (but it provokes some questions, that i don't like). Generally
>> there is REALLY many gui that works like that (one level down or up at
>> a time) just look around (eg all file explorers) and it's all you
>> need, because its basically same context!
>
> Same context? What context, the folder listing is per folder, besides
> nowadays the file explores have abandon the tree view in favor of more
> simple one level like nautilus. But even with gui that uses tree view
> we can only jump one level or to the root so it is not that it would
> save that much of time.

-- 
Slawomir Bochenski
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux