From: Wendy P. <Wen...@en...> - 2001-02-20 21:55:32
|
Yes. We can use versioning, but as long as we are at this juncture, why create the problem in the first place. Surely we can come up with a new name for the library that doesn't require versioning to get it right. Remember, customers call in and give sometimes interesting as opposed to real data. Are you running libprint? yes. Which version? uh, then comes the interesting bits. If they have different names, it's a whole lot easier on everyone. -Wendy > > > > We can use a new soname. > > > > So are you saying that we make the library we are working on now have a > > different name as in when you look in /usr/lib/libprint.so and > > /usr/lib/lib<somethingelse>.so or are you saying that "we" as in Sun can > > rename our library to something other than libprint? > > I'm saying that we (as in the participants on this list) can ship a library > called libprint which has a major version of 3 so that it can coexist next > to the (old and soon to be deprecated) Solaris libprint, which has a major > version of 2. The dynamic linker will take care of the rest. > > Danek > > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > http://lists.sourceforge.net/lists/listinfo/lpr-discuss > |
From: Wendy P. <Wen...@en...> - 2001-02-21 18:53:51
|
> > 1) Naming conventions - I think that the Sun people should come up > with what they want and bounce it off of "the solaris exported > interfaces naming committee" and "POSIX compliance committee". I have > very little interest in the naming convention. I would like nothing > more than to make suggestions such as "pr" seems too short. OK. We can do that. I've started discussions with the standards people on our end about the <mummble>_t posix question. Let's see if this can be sorted out by Friday. I care about namespace, not names. My personal preference is to not use capitals in variable names, but then if you've seen me type you'd understand. The use of under_bar is clearer for me than use of Capitals. > > 2) Structure, and manipulation of attributes as associated with > printer configuration - This is also a place where I think that the > Sun people should make the decisions because that is going to be the > area where they contribute the most code. ok > > 3) Job/document submission - This is where the spooler interacts with > the library. This is where the bulk of my code contribution is going > to be. I'd like to be the one who controls those interfaces. Yes and maybe and ... It appears to be that we still have a disconnect concerning documents and their relationship to jobs. Perhaps a round of email just on this topic would be useful. I view the job as containing all the documents that the user submitted with the print command. It's the job with embedded documents that allows the user to cancel/modify/move etc the entire contents of the job. The public interface doesn't show this connection as it stands. > > 4) Structure and manipulation of attributes as associated with jobs > and documents - I would like the attributes for jobs and documents to > be the similar enough to printer attributes that we can use the same > functions manipulating them but beyond that I don't care. In my > version, I use the same type. > > 5) Queue functions - Who ever writes the first queue engine (probably > me) should define the interface to it. We haven't gotten there yet. > > -ben > > > > > On Tue, Feb 20, 2001 at 02:20:22PM -0800, Wendy Phillips wrote: > > > > > Disagree. This is not an evolution of the current print system; it is a > > > brand new <bout time> printing sub-system. There will be a day when the > > > user can choose between the old and the new; the same name just adds > > > confusion and not much value. libprincess/libprintsys/??? --- don't > > > know what name to use; a new name indicates a new system, which, it is. > > > > It's still a printing system, though. Regardless of the fact that under > > the hood we've replaced parts, added new ones, taken away old ones, and > > shined everything up, it's still essentially the same beast. > > > > You mention that people will choose between old and new. Can they choose > > the old one now? How do you compile against libprint.so.2? There's no .h > > file. Solaris is the only consumer of that interface, and, once we make > > the switch, there will be *no* consumer. Revving the major number (and > > relinking the .so to point to .so.3) provides for a simple, programmatic > > way of saying that .2 is deprecated and don't use that any more, without > > breaking anything that's currently linked to it. > > > > I think that a new name just adds confusion and not much value, but neither > > of our arguments along those lines has much substance. > > > > Danek > > > > _______________________________________________ > > Lpr-discuss mailing list > > Lpr...@li... > > http://lists.sourceforge.net/lists/listinfo/lpr-discuss > > |
From: Ben W. <be...@va...> - 2001-02-21 20:53:55
|
> > 3) Job/document submission - This is where the spooler interacts with > > the library. This is where the bulk of my code contribution is going > > to be. I'd like to be the one who controls those interfaces. > > Yes and maybe and ... It appears to be that we still have a disconnect > concerning documents and their relationship to jobs. Perhaps a round > of email just on this topic would be useful. > > I view the job as containing all the documents that the user submitted > with the print command. It's the job with embedded documents that allows > the user to cancel/modify/move etc the entire contents of the job. The > public interface doesn't show this connection as it stands. Keep in mind we haven't even begun to talk about how we are going to do any queue modification commands. All the things that you mentioned cancel, modify, and move are queue modification commands and are not within the scope of what I'm calling job/document submission. Here is your code to create a job and submit a document: int main(int ac, char *av[]){ int data_len = 0; char data[BUFSIZ]; job_t *job = NULL; document_t *document = NULL; job = initialize_job(NULL); add_attribute(&job->attributes, "job-name", "test job"); add_attribute(&job->attributes, "job-printer", "glpr_test"); add_attribute(&job->attributes, "job-copies", "4"); add_attribute(&job->attributes, "job-owner", "mumblefrotz"); add_attribute(&job->attributes, "job-title", "Dune"); document = job->documents[0]; job->documents = (document_t **)list_append(job->documents, document); add_attribute(&document->attributes, "document-name", "Chapter 1"); add_attribute(&document->attributes, "document-format", "postscript"); add_attribute(&document->attributes, "document-data", "in-stream"); write(document->fd, data, data_len); document = initialize_document(job, NULL); add_attribute(&document->attributes, "document-name", "Chapter 2"); add_attribute(&document->attributes, "document-format", "postscript"); add_attribute(&document->attributes, "document-data", "pass-fd"); ioctl(document->fd, I_SENDFD, 0); commit_job(job); } Here is my representation of a similar thing. I associate two documents with one print job. Mine is shorter because I skip over setting all the attributes but they essentially do the same thing. int main(int argc, char **argv){ LPS_System_t *sys=lps_init(NULL); LPS_Printer_t *printer=lps_get_printer(sys,"lp",NULL); // no name service LPS_Job_t *job=lps_create_job(printer,NULL); // no job attributes unsigned int docid; int fd=lps_get_connection(job,NULL,&docid,2,FALSE); // no doc attributes int infd=open("foo",O_RDONLY); char buf[MAXBUF]; read(infd,buf,MAXBUF); write(fd,buf,MAXBUF); close(infd); close(fd); lps_send_ref(job,NULL,&docid,1,2,TRUE); // no doc attribs, last doc in job } In short your method is: 1) initialize a job 2) set job attributes (which include the printer and the owner) 3) initialize a document 4) set document attributes 5) write the job data 6) repeat steps 3-5 until all documents have been added. 7) commit the job Mine is: 1) initialize the print system 2) select a printer 3) assemble job attributes 3) create a job 4) assemble doc attributes 5) create a doc 6) write the job data 7) repeat steps 4-6 until all documents have been added If you notice they are fairly similar. I make the user jump through a few more hoops at the beginning and I request that all the attributes are assembled before the creation of an object but other than that they look about the same. When, we get to the point where we are fleshing out the API to the queue managers, that is where we will specify functions that will cancel jobs, modify existing jobs order in the queue, and move jobs between queues. At the point when we are writing the queue managers, the network protocol filters (e.g. sendipp) or writing the API to the queue managers, if we discover that I'm not preserving enough information to preserve the job/document semantics, then I'll have to reengineer some parts of the structures. However at this point, I've thought about it quite a bit and I think I can implement everything I need to with just the information that I've specified now. How I manage to preserve the proper semantics shouldn't really be something that you will need to worry about. All that you have to worry about is that I preserve the semantics. The semantics that I'm going to preserve are: 1) hold job, cancel job, move job's order in queue, and move a job from one queue to another apply to all the documents within a job rather than to just a document. 2) since the current version of IPP, and the LPR protocol do not currently allow document attributes to differ from job attributes, attributes are shared across all the documents in the job when necessary 3) overall job attributes are requestable at least in the case where the attributes are shared across many documents. 4) modifying job attributes changes all documents within that job. In addition, I may allow certain queue commands to apply to documents within a job (e.g. cancel a document out of a job) but I'm not going to guarentee that at this time. Please let me know if there are more semantics that I need to preserve. -ben |
From: Ben W. <be...@va...> - 2001-02-26 20:05:08
|
> > > > > 1) Naming conventions - I think that the Sun people should come up > > with what they want and bounce it off of "the solaris exported > > interfaces naming committee" and "POSIX compliance committee". I have > > very little interest in the naming convention. I would like nothing > > more than to make suggestions such as "pr" seems too short. > > OK. We can do that. I've started discussions with the standards > people on our end about the <mummble>_t posix question. Let's see if this can be > sorted out by Friday. I care about namespace, not names. My personal preference > is to not use capitals in variable names, but then if you've seen me type you'd > understand. The use of under_bar is clearer for me than use of Capitals. > Did you hear back from the guys at the top yet? > > 3) Job/document submission - This is where the spooler interacts with > > the library. This is where the bulk of my code contribution is going > > to be. I'd like to be the one who controls those interfaces. > > Yes and maybe and ... It appears to be that we still have a disconnect > concerning documents and their relationship to jobs. Perhaps a round > of email just on this topic would be useful. > > I view the job as containing all the documents that the user submitted > with the print command. It's the job with embedded documents that allows > the user to cancel/modify/move etc the entire contents of the job. The > public interface doesn't show this connection as it stands. So how do we stand on this? I sent another round of explaination and I haven't heard anything. I'm really anxious to get back to work on the spooler and the backend. Currently, the thing that is holding me up is that I applied all the changes that we agreed upon to libprintsys and I am working through getting them to compile. I need a working print library to be able to write and test the spooler. Most of the problem would go away if I threw away most of the printcap parsing and writing code that we wrote and used your princess code. If you give me your .c files, I'll be happy to integrate them if you don't want to. You do have write access to the repositories and so this is a matter of convience rather than access. -ben |
From: Carl K. <ku...@us...> - 2001-02-21 23:03:41
|
> 2) since the current version of IPP, and the LPR protocol do not > currently allow document attributes to differ from job > attributes, attributes are shared across all the documents in the job > when necessary The IPP attributes "document-name", "document-format", "compression", and "document-natural-language" are not considered job attributes -- these vary by document. Since the IPP model currently has no document object, there is no way to query these attributes. But they are used at document submission time. -Carl |
From: Danek D. <dd...@en...> - 2001-02-22 00:26:04
|
On Wed, Feb 21, 2001 at 04:04:44PM -0700, Carl Kugler wrote: > The IPP attributes "document-name", "document-format", "compression", and > "document-natural-language" are not considered job attributes Yeah. Bizarrely, they're considered operation attributes. I'm surprised they didn't have a document attribute group, even if none of the operations supported actions on individual documents. Danek |
From: Wendy P. <Wen...@en...> - 2001-02-26 20:36:38
|
> > > > > > > > > 1) Naming conventions - I think that the Sun people should come up > > > with what they want and bounce it off of "the solaris exported > > > interfaces naming committee" and "POSIX compliance committee". I have > > > very little interest in the naming convention. I would like nothing > > > more than to make suggestions such as "pr" seems too short. > > > > OK. We can do that. I've started discussions with the standards > > people on our end about the <mummble>_t posix question. Let's see if this can be > > sorted out by Friday. I care about namespace, not names. My personal preference > > is to not use capitals in variable names, but then if you've seen me type you'd > > understand. The use of under_bar is clearer for me than use of Capitals. > > > > Did you hear back from the guys at the top yet? > > > > 3) Job/document submission - This is where the spooler interacts with > > > the library. This is where the bulk of my code contribution is going > > > to be. I'd like to be the one who controls those interfaces. > > > > Yes and maybe and ... It appears to be that we still have a disconnect > > concerning documents and their relationship to jobs. Perhaps a round > > of email just on this topic would be useful. > > > > I view the job as containing all the documents that the user submitted > > with the print command. It's the job with embedded documents that allows > > the user to cancel/modify/move etc the entire contents of the job. The > > public interface doesn't show this connection as it stands. > > So how do we stand on this? I sent another round of explaination and I > haven't heard anything. > > I'm really anxious to get back to work on the spooler and the > backend. Currently, the thing that is holding me up is that I applied > all the changes that we agreed upon to libprintsys and I am working > through getting them to compile. I need a working print library to be > able to write and test the spooler. > > Most of the problem would go away if I threw away most of the printcap > parsing and writing code that we wrote and used your princess code. > > If you give me your .c files, I'll be happy to integrate them if you > don't want to. You do have write access to the repositories and so > this is a matter of convience rather than access. > > -ben > > |
From: Ben W. <be...@va...> - 2001-02-27 01:51:27
|
Ah I got it. I remember you saying something to that effect. I guess I sort of saw that as "Phase II". This explains why you were less interested in my printsys.h header file. In this arrangement, we can simply make "printsys.h" be a more or less internal header file. I'm glad, you have it to that level of integration. However, this brings up an interesting question of packaging. We are going to be retrofitting a huge number of systems for a comparitively long period of time until the distrobutions catch up the new version of glibc. For example, RH 7.0 came out just a few months ago. It will be almost a year until we are to RH 7.2 or 8.0 or whatever two releases down the road is. If we haven't submitted the patch to the glibc developers yet, then we certainly aren't going to make the 7.1 realease and the earliest that we could possibly get our stuff into the hands of users would be the 7.2 release near. Installing a new version of glibc is a fairly substantial retrofit. It is something that I wouldn't recommend many experienced users do without a very good reason. So what I suggest we do is a sort of 2 pronged approach. You continue along your path of making a patch to glibc and submitting it. This takes care of our long range (>1year) plan. However at the same time, while we are waiting for the glibc integration to go as planned, we also provide the exact same functionality via libprintsys. When the it is integrated into glibc, you stick it into "libprint.so". However, when we the local version of glibc doesn't include the necessary functions we include them into libprintsys which comes with the gnulpr package. We will use autoconf to select which version we use. At the very most libprintsys will be thin wrappers on the functionality of "libprint.so". I can work the autoconf magic to make this work. To accomplish this, what I would need to do is drop all the .c files and some tweaked versions of the header files into the libprintsys directory and then build a thin interface layer between what you and what I have. Finally, I'll integrate it into the autoconf/automake system so that the files do not get built unless they are needed. -ben > > Ben - > The printcap parsing routines come with the switch. It's a switch > backend that we have created. It will be in the new and improved > glibc, with access through the print library. > > This includes printers.conf, user, and nis. It will soon include ldap when > we get there. > > -Wendy |
From: James A. <ja...@an...> - 2001-02-27 04:14:17
|
Ben Woodard <be...@va...> writes: > When the it is integrated into glibc, you stick it into > "libprint.so". However, when we the local version of glibc doesn't > include the necessary functions we include them into libprintsys which > comes with the gnulpr package. We will use autoconf to select which > version we use. At the very most libprintsys will be thin wrappers on > the functionality of "libprint.so". I can work the autoconf magic to > make this work. I've probably missed something, but why are we trying to get it into glibc ? I didn't really want to mention anything before (as this seems to be a made decision) but the above looks like you are saying that you are always going to have/want a libprintsys anyway as glibc isn't released fast enough. It's also a given that *BSD aren't going to jump on the glibc bandwagon then I have ask what is the advantage of having it in glibc at all ? -- # James Antill -- ja...@an... :0: * ^From: .*james@and\.org /dev/null |
From: Ben W. <be...@va...> - 2001-02-27 04:30:12
|
> Ben Woodard <be...@va...> writes: > > > When the it is integrated into glibc, you stick it into > > "libprint.so". However, when we the local version of glibc doesn't > > include the necessary functions we include them into libprintsys which > > comes with the gnulpr package. We will use autoconf to select which > > version we use. At the very most libprintsys will be thin wrappers on > > the functionality of "libprint.so". I can work the autoconf magic to > > make this work. > > I've probably missed something, but why are we trying to get it into > glibc ? I have to admit that I kind of missed the reasoning behind that move myself. It was something that the Sun guys were working on when we were introduced to them. I simply took it at face value and thought having a, "getprinterbyname() function that used nsswitch seemed like a good idea to me. I also believe that it also kind of gives a layer of spooler indepenence to the whole thing. Sure we can be the people who distribute it if you don't already have it but if it is in glibc other spoolers might actually use it. > I didn't really want to mention anything before (as this seems to be > a made decision) but the above looks like you are saying that you are > always going to have/want a libprintsys anyway as glibc isn't released > fast enough. It's also a given that *BSD aren't going to jump on the > glibc bandwagon then I have ask what is the advantage of having it in > glibc at all ? > Like I said, I really think that we need to have a copy of the same .c files in libprintsys and we need to use automake to make sure that it all works together. The other advantage that I see in doing this is libprintsys may live in our CVS tree BUT it can be built as a stand alone module and therefore be uncoupled from the spooler. This is another avenue for people not interested in using gnulpr or not running linux but still needing access to the functionality that the Sun functionality have. -ben > -- > # James Antill -- ja...@an... > :0: > * ^From: .*james@and\.org > /dev/null |
From: Danek D. <dd...@en...> - 2001-02-20 22:10:43
|
On Tue, Feb 20, 2001 at 01:56:16PM -0800, Wendy Phillips wrote: > Yes. We can use versioning, but as long as we are at this juncture, why > create the problem in the first place. Surely we can come up with a new > name for the library that doesn't require versioning to get it right. Well, we're evolving a library that already exists. The (major) version is part of the name, as far as the linker is concerned, so whether we use `sys' or `3', roughly the same thing is going on internally. Printing is what this library supports, so `print' makes sense as a name. I think Solaris customers (and everyone else, for that matter) will be confused by `princess', and `printsys' is verbose (but I've made my penchant for terseness in names obvious). I get the impression that Ben probably would have called his library libprint if he hadn't known about our libprint. This is what library versioning is for. I think different names should be reserved for wholly different functionality. In addition, no one should be linking to our library anyway, as we don't provide header files, and it's our own private interface, anyway (despite being in /usr/lib). Danek |