Hi
On Thu, Jun 6, 2013 at 12:36 AM, Alon Levy wrote:
> >
> > @@ -1475,6 +1543,7 @@ static void port_opened(SpiceChannel *channel,
> > GParamSpec *pspec,
> > /* only send a break event and disconnect */
> > if (g_strcmp0(name, "org.spice.spicy.break") == 0) {
> > s
Looks good except for an unrelated bit you left in there, marked below.
> ---
> gtk/spicy.c | 102
> +++-
> 1 file changed, 95 insertions(+), 7 deletions(-)
>
> diff --git a/gtk/spicy.c b/gtk/spicy.c
> index dff9d44..0b5b1ea 100644
> --- a
On 06/05/2013 07:08 PM, Uri Lublin wrote:
On 06/05/2013 03:21 PM, Christophe Fergeau wrote:
On Wed, Jun 05, 2013 at 01:07:16PM +0300, Uri Lublin wrote:
In your example, query is "my_param=/some/path" and path points
to "/some/path" within query. Some may find it confusing, and it
does not
fol
On 06/05/2013 03:21 PM, Christophe Fergeau wrote:
On Wed, Jun 05, 2013 at 01:07:16PM +0300, Uri Lublin wrote:
In your example, query is "my_param=/some/path" and path points
to "/some/path" within query. Some may find it confusing, and it does not
follow URI syntax where path comes before query
See spice.proto RFC
---
server/reds.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/server/reds.c b/server/reds.c
index ae02e09..dd3005d 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1455,7 +1455,8 @@ static int reds_send_link_ack(RedLinkInfo *link)
ack.
Hi,
Here is a proof of concept patch series implementing a NBD channel, to
allow mounting block devices from a Spice client, such as ISO images
for cdrom drives.
There are very few Spice specific protocol changes, since the protocol
is handled mostly by NBD. The protocol to allow switching block
---
gtk/spicy.c | 102 +++-
1 file changed, 95 insertions(+), 7 deletions(-)
diff --git a/gtk/spicy.c b/gtk/spicy.c
index dff9d44..0b5b1ea 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -97,6 +97,7 @@ struct spice_connection {
SpiceSessi
- Mensaje original -
> See spice.proto RFC
> ---
> server/reds.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/server/reds.c b/server/reds.c
> index ae02e09..dd3005d 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -1455,7 +1455,8 @@ static in
This allows to use conveniently GIOStream APIs without caring about
coroutine and Spice messages details.
---
gtk/Makefile.am | 2 +
gtk/channel-base.c | 48 ++
gtk/channel-port.c | 33 +---
gtk/spice-channel-priv.h | 8 +
gtk/vmcstream.c | 436 +
This channel implements the NBD protocol and the port events defined by
Spice protocol.
---
doc/reference/spice-gtk-docs.xml | 1 +
doc/reference/spice-gtk-sections.txt | 18 ++
doc/reference/spice-gtk.types| 3 +-
gtk/Makefile.am | 16 +-
gtk/channel-nbd.c
When leaving a coroutine, it swaps back to where it came from, not to
the leader/main coroutine.
---
gtk/coroutine_ucontext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c
index af811a7..6d2f74a 100644
--- a/gtk/coroutine_uc
The NBD channel is a specialized port channel which implements the NBD
protocol over the Data messages (the NBD server implementation may not
implement the whole protocol, for example, it may be read-only, but
should reply with appropriate errors where required)
To allow to gracefully switch NBD s
Hi,
On 06/05/2013 03:31 PM, Marc-André Lureau wrote:
Hi
- Mensaje original -
When copy and pasting between a Linux guest and a Windows client or visa
versa, the line-endings of the text will usually be wrong for the other side,
so it is desirable to do automatic conversion.
However so
Hi
- Mensaje original -
> When copy and pasting between a Linux guest and a Windows client or visa
> versa, the line-endings of the text will usually be wrong for the other side,
> so it is desirable to do automatic conversion.
>
> However sometimes it is possible for text in the clipboar
When copy and pasting between a Linux guest and a Windows client or visa
versa, the line-endings of the text will usually be wrong for the other side,
so it is desirable to do automatic conversion.
However sometimes it is possible for text in the clipboard on Linux to have
MSDOS (CRLF) style line-
On Wed, Jun 05, 2013 at 02:48:54PM +0200, David Jaša wrote:
> IIRC there used to be a generic parser for URIs in glib that was removed
> at some point of time, didn't you think about making this code more
> generic so that each and every URI-parsing glib app doesn't have to go
> through these hoops
Just for the record: path is part of hierarchical part of the uri that
begins with double slash "//". Query part of the URI starts with
question mark "?" and it is followed by Fragment part that starts with
hash "#". So this is perfectly legal URI:
spice://fqdn?param=value
that contain just schem
On Wed, Jun 05, 2013 at 01:07:16PM +0300, Uri Lublin wrote:
> In your example, query is "my_param=/some/path" and path points
> to "/some/path" within query. Some may find it confusing, and it does not
> follow URI syntax where path comes before query (IIUC).
This is not meant to move the 'path' p
On 06/05/2013 11:23 AM, Christophe Fergeau wrote:
On Wed, Jun 05, 2013 at 11:15:47AM +0300, Uri Lublin wrote:
On 06/04/2013 05:19 PM, Christophe Fergeau wrote:
When parsing an URI, spice_uri_parse currently first looks up for
'/' to detect the 'path' part of the URI
(http://foo.example.com/some
On Wed, Jun 05, 2013 at 11:15:47AM +0300, Uri Lublin wrote:
> On 06/04/2013 05:19 PM, Christophe Fergeau wrote:
> >When parsing an URI, spice_uri_parse currently first looks up for
> >'/' to detect the 'path' part of the URI
> >(http://foo.example.com/some/path) and then the query part (starting
>
On 06/04/2013 05:19 PM, Christophe Fergeau wrote:
When parsing an URI, spice_uri_parse currently first looks up for
'/' to detect the 'path' part of the URI
(http://foo.example.com/some/path) and then the query part (starting
with '&' is looked up).
However, this does not work as expected when th
21 matches
Mail list logo
