Re: Reauthentication EINTR bug

On Mon, Jul 05, 2010 at 01:23:15PM -0700, Roland McGrath wrote: > > This would be ideal, but my current understanding is that > > interrupt_operation() is mostly advisory and that the operation will > > restart or return EINTR regardless of what the server does, and if this > > is true then it is i

Re: What do you need from the Hurd for your day-to-day tasks?

On Mon, Jul 12, 2010 at 08:41:49AM +0200, Arne Babenhauserheide wrote: > What is missing for you? Sound support, wireless, and PPPoE. I could probably factor out these to a seperate router/sound box but at that point I might as well just run Hurd in in kvm and use the host as the support box, wh

Re: hurdextras in git?

Hi, On Mon, Jul 12, 2010 at 03:24:53PM +0200, Arne Babenhauserheide wrote: > Are the hurdextras already in git? No, only unionfs: . > They have some very interesting translators, and these should be easily > available. > > And easily doesn’

Re: hurdextras in git?

Hi, On Tue, Jul 13, 2010 at 03:23:51AM +0200, Arne Babenhauserheide wrote: > > > They have some very interesting translators, and these should be easily > > > available. > > > And easily doesn’t mean cvs :) > > > > Yeah, definitaly. > > Should all be in one repository with different subfolders o

Re: Fixing grub-probe to work with user-space part stores

Hi, On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote: > The first one would be to make part.c embed extra information in its > stores and their encoded form (possibly in the "misc" fiels of a remap > store). This would force it to create a new layer instead of reusing > the underlyin

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote: > On 15/07/10 17:05, Emilio Pozuelo Monfort wrote: > > On 15/07/10 16:49, Emilio Pozuelo Monfort wrote: > >> Here it goes, with a good commit message: > > > > Forgot to add the file before committing :( > > Also check th

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

Hi, On Sat, Jul 17, 2010 at 11:37:34AM +0200, Emilio Pozuelo Monfort wrote: > On 15/07/10 20:46, Carl Fredrik Hammar wrote: > > On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote: > > The first thing you should do in any RPC that is not a stub is:

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

On Sat, Jul 17, 2010 at 12:25:48PM +0200, Carl Fredrik Hammar wrote: > Hi, > > On Sat, Jul 17, 2010 at 11:37:34AM +0200, Emilio Pozuelo Monfort wrote: > > + *(int*)*value = user->sock->pipe_class->sock_type; > > + *value_len = sizeof (int); > > + b

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

On Sat, Jul 17, 2010 at 03:36:43PM +0200, Ludovic Courtès wrote: > Emilio Pozuelo Monfort writes: > > > error_t > > S_socket_getopt (struct sock_user *user, > > int level, int opt, > > char **value, size_t *value_len) > > { > > - return EOPNOTSUPP; > > + int ret = 0

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

Hi, On Fri, Jul 16, 2010 at 12:13:56PM +0200, Emilio Pozuelo Monfort wrote: > On 31/05/10 18:27, Carl Fredrik Hammar wrote: > > I have reviewed the patches and apart from formatting there were only > > a couple of issues. Next iteration is hopefully the last. > > I hope s

Re: [PATCH 2/3] Add a file_exec_file_name RPC

On Fri, Jul 16, 2010 at 12:15:06PM +0200, Emilio Pozuelo Monfort wrote: > >From 3804a36fcf95a3fd588ce67a08a36346134b8d1f Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Wed, 26 May 2010 01:27:40 +0200 > Subject: [PATCH 2/3] Add a file_exec_file_name RPC > > * hurd/fs.defs (f

Re: [PATCH 3/3] Use the new _hurd_exec_file_name function

On Fri, Jul 16, 2010 at 12:17:38PM +0200, Emilio Pozuelo Monfort wrote: > Note that this patch should only be applied after the glibc patch is applied, > and maybe some time later (perhaps after a stable release shipping it?). I think the commit order will need to be brought up at today's meeting.

Re: [PATCH] Use the new __hurd_exec_file_name RPC

On Fri, Jul 16, 2010 at 12:21:16PM +0200, Emilio Pozuelo Monfort wrote: > And here goes the glibc one. > > Regards, > Emilio > > 2010-07-16 Emilio Pozuelo Monfort > * hurd/hurdexec.c (_hurd_exec): Deprecate it. > (_hurd_exec_file_name): New function. > * hurd/hurd.h: Declare

Re: [PATCH] Bump HURD_INTERFACE_VERSION

On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote: > >From 03b291be17be4beb67d7397526c1ae7c292649df Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Thu, 15 Jul 2010 20:37:20 +0200 > Subject: [PATCH] Bump HURD_INTERFACE_VERSION > > * hurd/version.h (HURD_

Re: [PATCH] Use the new __hurd_exec_file_name RPC

Hi, On Sat, Jul 17, 2010 at 02:07:19PM +0200, Guillem Jover wrote: > On Fri, 2010-07-16 at 12:21:16 +0200, Emilio Pozuelo Monfort wrote: > > And here goes the glibc one. > > > diff --git a/hurd/hurd.h b/hurd/hurd.h > > index 642ea43..a83c3fa 100644 > > --- a/hurd/hurd.h > > +++ b/hurd/hurd.h > >

Re: [PATCH] pfinet: check return value of mmap() in S_io_read() and S_socket_recv()

Hi, On Thu, Jul 22, 2010 at 12:16:08PM +0200, olafbuddenha...@gmx.net wrote: > I realized that my problems with pfinet crashing after apt-get fetching > ~90 MB of packages, are due to a gaping virtual memory leak in pfinet. > (Probably the same one Samuel fixed recently; but I haven't tested his >

Re: [PATCH 2/3] Add a file_exec_file_name RPC

Hi, On Mon, Jul 26, 2010 at 07:32:04PM +0200, Emilio Pozuelo Monfort wrote: > @@ -159,14 +193,28 @@ diskfs_S_file_exec (struct protid *cred, >do > { > right = ports_get_send_right (newpi); > - err = exec_exec (execserver, > -right, MACH_MSG_TYPE_

Re: [PATCH] Use the new file_exec_file_name RPC

Hi, On Mon, Jul 26, 2010 at 07:42:25PM +0200, Emilio Pozuelo Monfort wrote: > Also I've tested with the Debian package (which is at 2.11.2) so I > needed to change the Versions file. I changed it to 2.11.2, but I > got quite some warnings that GLIBC_2_11_2 was undefined. I changed > it to 2_11 and

Re: exec server and /dev/fd/N

Hi, On Mon, Jul 26, 2010 at 07:28:42PM +0200, Emilio Pozuelo Monfort wrote: > New iteration. All mentioned issues have been fixed, except for the glibc > check > for the file_exec_file_name RPC, which I don't know how to do if not using > HURD_INTERFACE_VERSION. Any suggestions are welcome. I ha

Re: [PATCH 3/3] Use the new _hurd_exec_file_name function

Hi, On Mon, Jul 26, 2010 at 07:33:58PM +0200, Emilio Pozuelo Monfort wrote: > >From c6276e2df1d370dbbdd7f4e6fb388f241f84fee7 Mon Sep 17 00:00:00 2001 > From: Emilio Pozuelo Monfort > Date: Wed, 26 May 2010 23:32:16 +0200 > Subject: [PATCH 3/3] Use the new _hurd_exec_file_name function > > * conf

Re: [PATCH] Add support to send file descriptors over Unix sockets

Hi, On Tue, Jul 27, 2010 at 08:08:36PM +0200, Emilio Pozuelo Monfort wrote: > > This patch adds support for SCM_RIGHTS to glibc. It works fine > when sending file descriptors from a socket() or a socketpair() call, > but not from e.g. an open() call, as I've mentioned in another mail. > That's no

Re: Fixing grub-probe to work with user-space part stores

Hi, On Tue, Jul 27, 2010 at 08:22:14PM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Jul 14, 2010 at 07:51:07PM +0200, Carl Fredrik Hammar wrote: > > On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote: > > > > The first one would be to make part.c embed ext

Re: [PATCH 2/8] Avoid hashing garbage for short keynames.

Hi, On Wed, Aug 11, 2010 at 07:04:17PM -0300, Diego Nieto Cid wrote: > Hi, > > 2010/8/9 : > > > > Hm, why tmp[5]? The way I read the code, only 4 entries are used... > > > > Well it's the null that terminates the string. But as this isn't used > as a string it probably does not make much sense.

Re: GSoC meetings

Hi, On Sun, Aug 22, 2010 at 11:18:41AM +0200, olafbuddenha...@gmx.net wrote: > > First of all, I'm not sure I will be able to make it to the meeting > tomorrow. (Am at FrOSCon right now :-) ) But as usual, that shouldn't > stop the others from meeting. Sure, have a good time. :-) > I guess we

Re: GSoC meetings

On Fri, Aug 27, 2010 at 01:51:09AM +0200, Emilio Pozuelo Monfort wrote: > On 22/08/10 11:18, olafbuddenha...@gmx.net wrote: > > I guess we will soon need to come up with a new meeting schedule, now > > that the summer session is almost over: go back to meeting once a week; > > and probably account

Re: Google Summer of Code project: libchannel

Thomas Schwinge <[EMAIL PROTECTED]> writes: > Hello! > > On Tue, Mar 20, 2007 at 09:22:12PM +0100, Fredrik Hammar wrote: >> first up let me introduce myself [...] > > Welcome, Fredrik! > Thanks! >> get it running on Xen. > > That basically works, but still has a number of sharp edges and slippe

GSoC libchannel project draft

Hello again! I have finished writing a draft for the proposal I intend to submit to Google Summer of Code which I have appended to this mail and I would appreciate it if someone took their time to read it through. Since the project could basically be summed up as ``libstore for character devices'

Re: GSoC libchannel project draft

Richard Braun <[EMAIL PROTECTED]> writes: > Hello, > > There are two main points I want to discuss about. > > First, in your example about pfinet (device-tunnel-pfinet), I don't see > the need for a single format. Such an abstraction could force the > implementation to ignore some important bits,

Re: GSoC libchannel project draft

I have attached the second revision of my proposal which I will send in tomorrow. It addresses the concerns made by Richard. I decided to not to make an attempt at a sketch of handling ioctls, but handling them are included as a part of the project's goals. I also made a commitment of having a c

Re: Carl Fredrik Hammar to work on libchannel

Thomas Schwinge <[EMAIL PROTECTED]>, Richard Braun <[EMAIL PROTECTED]> writes: > Hello! > Hi! > bug-hurd, please welcome Carl Fredrik Hammar, who will be working on > <http://savannah.gnu.org/task/?1619>, ``designing and writing libchannel, > a library for stre

Re: Carl Fredrik Hammar to work on libchannel

> W00t, welcome Fredrik, and good luck!!! > > Barry deFreese (aka bddebian) Thanks Barry! Fredrik ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GSoC project libchannel

Thomas Schwinge <[EMAIL PROTECTED]> writes: > Hello! Hi! > Downward from the heights where the tower is installed in which the Hurd > administration resides ;-) I'm asking the question: what is the state of > this year's GSoC project, libchannel? Fredrik, how are you coming along? Well to be h

Copyright notice

ion, Inc. Written by Carl Fredrik Hammar <[EMAIL PROTECTED]> This file is part of the GNU Hurd. Would this be appropriate, or should I reset the copyright years? Should I keep Miles Bader as an author? Should I break the overly long copyri

libchannel progress report #1

Hello! Just thought I'd make a comment on the CVS commits I made yesterday and how I intend to proceed. The code isn't at all very substantial, it's pretty much a struct, a couple of defines, some very basic functions and a test, i.e. just some infrastructure for things to come. In terms of prog

[libchannel] Control procedures

Hello, I'm currently thinking up how channel's control interface (a la ioctl) will look like and I need some input. I have a fairly good idea of how the backend will look like in libchannel itself (more on this once the following is resolved.) But getting dynamically extensible IPC for it is a b

Re: [libchannel] Control procedures

"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > I agree with Pierre, please provide some examples. Ah yes, examples, examples. I've mostly been going by the following passage from an old archive mail about libchannel written by Marcus (http://people.debian.org/~terpstra/message/20020130.174030.

Re: [libchannel] Control procedures

Ok, I think I figured out a proper solution, for clarity I will reiterate the entire solution. It's a lengthy mail, but please do read it and tell me what you guys think about it. We want to implement a .defs file with control procedures, which can ofcourse be independant of libchannel. The only

[GSoC libchannel] Specification

Hello, this is my first atempt at a (mostly) complete specification for libchannel. Perhaps a bit to detailed and lenghty to give a nice overview, but I trust you can filter out the noise. I would appreciate it if Richard, Roland and Marcus would have a look at it. But also from anybody else, o

Re: Doxygening Mach and Hurd

Hello! Michael Casadevall <[EMAIL PROTECTED]> writes: > During my time correcting the entropy patch to meet the requirements > to be accepted, I noticved the coding style would make it extremely > easy to doxyify the codebase. > > For those of you unfamilar with Doxygen, its similar > to Javadoc

Re: Doxygening Mach and Hurd

Michael Casadevall <[EMAIL PROTECTED]> writes: > I don't believe the documentation should even list all the functions > though. For instance, say you were working on the entropy driver, > which doesn't have a public API; the only source of documentation > would be the comments left behind. It

Channel sessions

Hello! I've thinking about use-cases for libchannel and started work on channelio for the last few days and it got me thinking about sessions. I found that I've been assuming that character devices are session-less, mostly because they, unlike stores, are not seekable. Now I'm not so sure that is

Re: Channel sessions

<[EMAIL PROTECTED]> writes: > Hi, > > On Thu, Jul 19, 2007 at 09:35:01PM +0200, Carl Fredrik Hammar wrote: > >> Suppose we want to record some audio which we may read from >> /dev/sound/audio, which is a channelio translator. Additionaly we >> want to broadca

Re: Channel sessions

Hello, <[EMAIL PROTECTED]> writes: > Hi, > > On Sun, Jul 22, 2007 at 03:56:41PM +0200, Carl Fredrik Hammar wrote: > >> Having special channel classes (or perhaps some other type of modules) >> for it seems like the right way to go. But the problem that these &

Re: Channel sessions

Hello, after some careful thinking I think I have pretty good idea of how to handle sessions, demuxing and buffering. My solution is simple enough; they should all be implemented in channels (as opposed to being implemented in channelio.) This will be more general and give the user more control.

Re: Channel sessions

ully this will clear things up. <[EMAIL PROTECTED]> writes: > Hi, > > On Thu, Jul 26, 2007 at 09:24:32PM +0200, Carl Fredrik Hammar wrote: > >> My solution is simple enough; they should all be implemented in >> channels (as opposed to being implemented in channelio.)

Naming per-translator instance (was Re: Channel sessions)

Hello! Carl Fredrik Hammar <[EMAIL PROTECTED]> writes: > So in conclusion, a channel is a per-open entity, while a channel > class is a per-server entity. When you layer channels you actually > layer channel classes, how the actual channels get layered is > class-specific. Th

Re: Channel sessions

Hello, <[EMAIL PROTECTED]> writes: > Well, I think we generally failed to define a clear terminology. Or > maybe you actually did, and I only fail to stick to it. In any case, to > make things clear, I'll explain what terms seem most logical to me. Let > me know what you think of that. I have so f

Re: Channel sessions

Hello, <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, Aug 13, 2007 at 03:08:27PM +0200, Carl Fredrik Hammar wrote: >> <[EMAIL PROTECTED]> writes: > >> I will use channel for the object that a client interacts with, i.e. >> one is created whenever the tra

Re: Channel sessions

Hello, <[EMAIL PROTECTED]> writes: > Hi, > > On Tue, Aug 14, 2007 at 02:15:46PM +0200, Carl Fredrik Hammar wrote: >> <[EMAIL PROTECTED]> writes: >> > On Mon, Aug 13, 2007 at 03:08:27PM +0200, Carl Fredrik Hammar wrote: > >> >> I will use

Re: Channel sessions

Hi, <[EMAIL PROTECTED]> writes: > Hi, > > On Wed, Aug 22, 2007 at 05:23:45PM +0200, Carl Fredrik Hammar wrote: >> <[EMAIL PROTECTED]> writes: > >> > Channel instances are pretty much of an internal detail IMHO. When a >> > user think

[bug #20906] libstore segfaults when failing to open multiple stores

URL: Summary: libstore segfaults when failing to open multiple stores Project: The GNU Hurd Submitted by: hammy Submitted on: Sunday 08/26/2007 at 17:59 Category: Hurd

[bug #20907] storeio: ENOENT on lookup causes clients to use underlying translator

URL: Summary: storeio: ENOENT on lookup causes clients to use underlying translator Project: The GNU Hurd Submitted by: hammy Submitted on: Sunday 08/26/2007 at 18:14 Category: Hurd S

[bug #20907] storeio: ENOENT on lookup causes clients to use underlying translator

Update of bug #20907 (project hurd): Status:None => Ready For Test ___ Reply to this item at: ___ Messa

Re: Hurd Sommer of Code infos

Arne Babenhauserheide <[EMAIL PROTECTED]> writes: > Hi, Hi Arne! Sorry for the late reply, your mail slipped under my radar for a while. > Can you post information about the summer of code projects for the HURD? I was the student that was involved in the only Hurd project in GSoC this year, w

Re: Hurd Sommer of Code infos

n Tue, Sep 18, 2007 at 08:59:15PM +0200, Carl Fredrik Hammar wrote: >> it ended up mostly completed, there are some small things I >> haven't gotten to yet and it needs more testing. It was passed by >> Richard, so officially it's a success. > > Congratulations to y

Re: Library/function documentation

Hello! > Hi, > > How do core developers go through Hurd servers/library or gnumach > functions? Do you use etags/ctags? Personally I use etags when browsing through code. > Wouldn't it be useful for newbies if all functions can have comments > to generate gtk-doc style documentation? > http://li

Critique of libchannel's design

Hello, I haven't been able to put any real work into libchannel for a while, but I have been brooding and scribbled down some ideas. So before my studies resume, I'd like to consolidate my thoughts into a text and hopefully get some feedback. This will done in a series of mails, this first one w

New channel concept

Hello, this is my second mail describing a new proposal for libchannel's design. In this mail I will redefine the channel concept to a more useful abstraction. Old channels are required to implement a subset of the Hurds io interface. But they also have the ability to implement arbitrary interf

Re: Critique of libchannel's design

<[EMAIL PROTECTED]> writes: > Hi, > > On Sat, Jan 05, 2008 at 06:54:55PM +0100, Carl Fredrik Hammar wrote: > >> I'd like to consolidate my thoughts into a text and hopefully get some >> feedback. This will done in a series of mails, this first one will be >

Re: New channel concept

Hello, <[EMAIL PROTECTED]> writes: > Hi, > > This time I have a bit more to say... ;-) Indeed. :-) >> There are also objects which I have called ``channel hubs'' (yuck!), >> that act as trivial filesystem objects, and they implement a subset of >> the Hurds fs interface. > > Let me get this righ

Re: Google Summer of Code participation

Hello, <[EMAIL PROTECTED]> writes: > Hi, > > For those who haven't heard it yet on IRC (and also a reminder for the > others): Unlike the last two years, when we only participated under the > umbrella of the GNU project, this year we want to participate in GSoC as > an organisation on our own. T

Re: Google Summer of Code participation

Hi, <[EMAIL PROTECTED]> writes: >> > Especially the project list needs work. Some of the project >> > descriptions are only skeletons; I lack the knowledge to fill in the >> > details. But I know that some of you have much better understanding >> > about some of these projects. >> >> I noticed `

Re: GSoC application deadline passed

Hello Arne! > But there is something I direly miss in the HURD, and that doesn't have > anything to do with its actual code, but with how it can be accessed and > seen. > > When we had the HURD in my informatics class, one task was to find out > information about the HURD, and as I searched fo

Re: GSoC application deadline passed

Hi, > You can access the git back-end directly. Unfortunately there ae no > instructions on how to access it on the wiki (or anywhere else it > seems). I'll try to fix it once I figure it out myself. :-) Oh wait! Instructions are here: http://www.bddebian.com/~wiki/contributing/wiki/index.htm

Re: Wiki slowness

Hi, > BTW, I wonder why the wiki modifications should be so slow. Are there > so many things to do in the wiki engine to perform that action? It > looks to me like there's rather a nasty timeout elapsing somewhere. > > Samuel Ikiwiki seems to recompile markdown to html after every change. If i

Re: Requesting for review of the Draft proposal for - procfs

Hi, I was the student in GSoC last year, just thought I'd share my acquired wisdom and drop some comments on your proposal. :-) > [snip] > > I have come up with this draft proposal so that we can discuss further > based on the this proposal. I have roughly consolidated my ideas from the > abov

Re: Requesting for review of the Draft proposal for - procfs

Hi, > Hi Carl, > Thanks a lot in spending your invaluable time in going through my > proposal. No problem. Also, I go by Fredrik not Carl, a misconception that is easy to make since I don't abbreviate it. :-) > [snip] > > I suspect you will need to narrow down your feature list a bit. Not >

Re: Requesting for review of the Draft proposal for - procfs

<[EMAIL PROTECTED]> writes: > I don't quite see the need for a special library here -- what would it > provide over plain libtrivfs?... It seems to me that many (most?) of the translators will be /very/ simple. For uptime, cpuinfo, cmdline etc. their task boils down to gather some info and produ

Re: Requesting for review of the Draft proposal for - procfs

Hi, > I want to bring few points to your notice, though I had understood > the need for GNU/Linux compatibility of the procfs that is to be > implemented, I always felt that the GNU System should be always ahead of > the GNU/Linux or anyother systems, either in terms of design, or > performance

Re: Gsoc: choosing right project for hurd.

Hi, > I dont know if this is the right list for this question. I apologize > if it is the wrong forum. No worries, this is the right one. :-) > I am quite unsure which project to choose from the list. I originally > applied for procfs project and i got a suggestion to apply for another > pro

Re: updated proposal

Hi, > Olaf made some comments on my proposal and wanted to know a bit more about > my actual implementation in the Hurd itself. I've done added a bit more > to the proposal to explain what I feel is a good implementation. > Basically, I was thinking the network stack could be divided into > diff

Re: Requesting for review of the Draft proposal for - procfs

Hi, I think you've done a really great job of writing this proposal! There's not much to comment on really. :-) "Madhusudan C.S" <[EMAIL PROTECTED]> writes: > The project thus aims at making the GNU/Linux process management > tools like ps, top, vmstat, sysctl, w, kill, skill, nice, snice, > pgr

Re: Requesting for review of the Draft proposal for - procfs

Hi, > > I'm fully available this summer without any other commitments, will > > tune my day/night rhythm as per my mentor's requirement and assure a > > dedicated work of 50 hours/week. > > Wow, 50 hours a week is a lot. I didn't put nearly as much time into > my GSoC project, I think 2

Re: Requesting for review of the Draft proposal for - procfs

Hi, <[EMAIL PROTECTED]> writes: > I totally agree that it would be desirable to have a library that help > writing such *really* trivial translators. (libtrivtrivfs?... ;-) ) (Looking in a thesaurus.) How about, micro, puny, trite, scanty...? Wait I think we have a winner libweefs. ;-) > I thi

Re: Requesting for review of the Draft proposal for - procfs

Hi, > BTW, there is a problem: We have another very promising application for > the procfs task. If we want to take both of you, one would have to > switch to a different task. Would you be willing to work on something > else as well? I know it's unfortunate, as you have already put so much > work

Re: purpose for xmlfs improvment -GSoC application -

Hi, Charly Caulet <[EMAIL PROTECTED]> writes: > Hello, > > I have wrote some possibilities of xmlfs improvment in that document > (http://deux-fleurs.net/analyse-xmlfs). > > I would like to discuss my choices. So please, send comments and ideas. My first reaction is that the order of nodes is to

Re: purpose for xmlfs improvment -GSoC application -

Hi, <[EMAIL PROTECTED]> writes: > On Tue, Apr 22, 2008 at 02:34:26PM +0200, Carl Fredrik Hammar wrote: > >> One possibility would be to simply prefix the non-attribute nodes with >> numbers, e.g. `1 author', `2 title', `3 isbn'. The problem here >>

Re: An idea for versiont racking using translators

Hello, On Tue, Aug 26, 2008 at 01:15:51PM +0200, Arne Babenhauserheide wrote: > Hi, > > This is just a general idea which struck me: > > With translators it would be easily possible to hide version tracking > activity > by just stacking a version tracking translator over some directory. >

<    1   2   3